Hitachi Vantara Pentaho Community Forums
Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: JasperReports vs JFreeReports

  1. #1
    Join Date
    Mar 2003

    Default JasperReports vs JFreeReports

    Anyone know what the major differences between these are?

    Which is better?

  2. #2
    Join Date
    Mar 2003

    Default Re: JasperReports vs JFreeReports

    I'm very intereset too



  3. #3
    Join Date
    Mar 2003

    Default Re: JasperReports vs JFreeReports

    mail me

  4. #4
    Join Date
    Mar 2003

    Default Re: JasperReports vs JFreeReports


    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.

    * 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

    * 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
    * 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
    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

  5. #5
    Join Date
    Mar 2003

    Default Re: JasperReports vs JFreeReports


    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,

  6. #6
    Join Date
    Mar 2003

    Default Re: JasperReports vs JFreeReports

    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

  7. #7
    Join Date
    Mar 2003

    Default Re: JasperReports vs JFreeReports

    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.

  8. #8
    Join Date
    Mar 2003

    Default Re: JasperReports vs JFreeReports


    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.


  9. #9
    Join Date
    Mar 2003

    Default Re: JasperReports vs JFreeReports

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


  10. #10
    Join Date
    Mar 2003

    Default Re: JasperReports vs JFreeReports


    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.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2017 Pentaho Corporation. All Rights Reserved.