JasperReports vs JFreeReports

[Anonymous]

Anyone know what the major differences between these are?

Which is better?

[Anonymous]

I'm very intereset too

cheers

Dirk

[Anonymous]

mail me

[Anonymous]

Hi,

although I don't know JasperReports very well, I'll try to compare both
projects. If there is something missing, let me know, I think this question
will pop up regulary, so every update is welcome.

To the comparison. Most features are common and both projects support them,
I'll list them here so that noone reports them missing later.

Both versions support the following features:
* XML, HTML, PDF, Graphics2D (Screen, java.awt.Images), Printer, CSV
* both systems support dynamic elements (Jasper calls this Stretching)
* image scaling is supported in both systems, additionally JFreeReport
supports dynamic image element, so that the bounds can extend themself
to fit the full image into the report.
* Band in Band composition
* both systems support userdefined functions in some way:
Jasper uses inline expressions which are evaulated at runtime and fill
their values into variables. Additionally there are explicit function classes
called scriplets. JFreeReport only uses explicit expressions and
functions which are queried at runtime and activated by report events
during the report definition. (this is the comparable to Jaspers Scriplets).
* Unicode is fully supported in the output
* Both systems can be used within Servlet-environments
* supported font styles: bold, italic, underline, strikethrough
* FontEncoding and FontEmbedding can be defined for every element

To the differences: Both projects have their own set of features, I'll just
list them. Again, if there's something missing, please tell me.

JasperReports
* has some userfriendly report designers.
* supports SubReports, Columns,Anchor elements
* needs precompiled reports and so a complete J2SDK installed
* JasperReports supports the printable interface for printing
* Jasper has a working example on how to integrate JFreeChart
* integrated JDBC-Query definition in the xml definition file
* uses custom datasource implementations


JFreeReport:
* complete on-the-fly report processing (j2RE needed, works without temporary files)
* advanced Layouting (relative positioning, layoutmanagers)
* stylesheets for element style-definitions, stylesheets can inherit their
default values from parent stylesheets.
* support huge reports (have a look at HugeJfreeReportDemo in the demo package)
* small memory footprint
* have a better internal design, our sourcecode is better documented
* our library designed to be easily integrated into other programms
(JFreeReport was (and is) never intended to be a standalone reporting application)
* a complete preview frame for JFrame, JDialog and JInternalFrame
* The reportpane-component can be used to easily create own PrintPreview applications,
the ReportPane fully supports the Pageable and Printable interface for custom
printing
* PDF, HTML, CSV export-targets have supportive Dialogs for use in own programms.
* As datasource, only a single TableModel can be used (will be extended in one of
the next releases)
* support for JDBC-ResultSets as datasource is supplied by using the
ResultsetTableModelFactory in the util-package.
* Advanced configuration interface, JFreeReport properties can be configured using
PropertyFiles or the system properties as well as using the internal API.
* supports Log4J logging
* our TTF-Font handling is easier to use than Jaspers Font handling as it most things
are automated so that the users doesn't need to care where the fonts are stored.
But if he cares, he is able to change everyting by using the API.


To all users out there, who has used both projects: What do you think about both programms?
And to all users: How could JFreeReport be more improved! What's missing or what would you
like to see implemented in the near future?

FYI I added the release plan for the next few releases, so you can see what's
already on the ToDo list:

in April:
0.8.2: Support for new Elements:
+ JFreeChartElement + supporting classes (DataSet creation etc).
+ Anchor Element and HyperLink elements
+ StyledDocumentElement (support for javax.swing.text.Document)
so that simple HTML and other formated text can be printed
Some more layoutmanagers
PlainText outputtarget (see the feature request on SF)

in Juni:
0.8.3: SubReports
Columns
Enhanced printing (distributing printed pages over multiple physical
pages / finally implement the Logical/Physical Page classses).
PageBreak within a band (to print the complete GPL and not just the
first page.

somewhere in the summer ...
0.8.4: Support for multiple source tables and a simple SQL-Style query
schema (I already have the parser and most of the implementation,
but these sources are old, they need some work).
... more things will appear, they always do ...


Have more fun,
said Thomas

[Anonymous]

Hi,

I'm also very interested to find out if there are any
users who have used both libraries and what they have
to say about all this.

I'm not very familiar with JFreeReport myself and I intervene here
just to make sure we have a more objective (if not complete)
JasperReports features list, like we already have for JFreeReport.

*Compiled report designs: in more than 90% of cases,
once a report design was created it is only used for
filling purposes and never changes. Or at least it does
not require runtime changes, but rather design time changes.
So, why parsing the XML over and over again and not keeping
it in a more ready to use form? XML parsing is generally
time consuming. After all, everybody compiles its java source
files and does not create and execute them at runtime.
The same goes for report designs.
This is mainly why JasperReports has this "report compilation"
phase. Just think about a compiled report design as a different
form to store your XML and it won't bother you anymore.

*Report parameters: you can pass any object reference as
a parameter to the report filling process, along with the
data source, to use in the report expressions.

*Data source: interface with default implementations for
wrapping ResultSet, JavaBeans collection, JavaBeans array
or TableModel objects.

*Report expressions: all report expressions (image, text,
variable or group expressions, etc) are real Java expressions
in which you can call methods on any class available in the classpath.
There are special expressions that allow you to skip
elements or even entire sections.

*Report variables: you can declare report variables that
perform built-in types of calculations like count, sum,
average, variance, min, max, etc. at report, page, column
or group level.

*Hyperlinks: These are useful for drilldown reports.

*Scriptlets: callback mechanism that gives great flexibility
to the report filling process, allowing further data processing
or runtime document customization.

*Subreports: you cannot go too far with your complex report
layouts if you don't have a way to break them into subreports.

*Samples : JasperReports is shipped with 19 report samples
detailing all major features of the library.
Often this is better than any source code documentation,
since you don't have to learn the API in order to start
creating your reports. The complete web application sample
provided is everything most users need to start publishing
their reports on the Web.
And generally speaking, if the code is not self-explaining,
then it is not good quality code.

*GUI tools : As someone once said, these GUI tools help
you "get rid of the ugly XML". Many thanks to all those who
took the time and created them. You only have to choose one.

*Flexibility : You have to take a look at the
JasperReports Quick Reference to have a glimpse of what
it can do for you.

*Performance and Memory : Just to convince myself this
is not a problem, I have generated a report using 150000 records.
It resulted in a document containing 7144 pages after
about 4 minutes.

Thank you,
Teodor

[Anonymous]

Hi Teodor,

it is great to have your description of Jasper-Report here, so the picture will be more complete now.

Now we just have to find some users opinions on this topic

Have more fun,
said Thomas

[Anonymous]

FWIW - We have a requirement to provide ad-hoc reports. That was a major reason for not wanting to have to have to compile the XML ahead of time.

[Anonymous]

Exactly.

Runtime report generation means that I can provide more user friendly and versatile programs. I include a report wizard/designer with JFreereport in my program, and this is awesome. Users comment that it is great to be able to design their own reports, because most programs only allow one or two report designs. Versatility is the key!

Locking people into a mechanism is imho not the best way.

Joe

[Anonymous]

Well, can you post your code for your wizard/generator if it is possible?

JMi

[Anonymous]

Hi,

I couldn't really post the code for this yet, as it is not really portable to applications not using my architecture. There is also a proprietary data-binding framework behind the system which prohibits me from releasing it. This may happen one day in the future, but not until i finish a few more projects at work.

Joe