Hitachi Vantara Pentaho Community Forums
Results 1 to 3 of 3

Thread: BIRT vs JFree

  1. #1
    Join Date
    Oct 2007
    Posts
    7

    Question BIRT vs JFree

    More of a general question than an actual problem:

    I have worked through a quite extensive Pentaho prototype using JFree reports. Recently I gave BIRT a shot (mainly due to another system we have in place adapting it as a new reporting standard) and I was very impressed by what BIRT delivers, especially compared to JFree.

    So my (provocative) question would be: Why even using JFree and his inferior report designer?
    (Or less provocative: What am I missing here, where does BIRT fall short?)

    Thanks for sharing your thoughts on this!

    Andreas

  2. #2
    Join Date
    Mar 2003
    Posts
    8,085

    Default

    Well, BIRTs report-designer looks a lot nicer than our Report-Designer 1.6, but RD 1.7 is clearly on its way to close the gap. But there's more to reporting than just the designer. With the upcoming Report-Designer 2.0, we will be able to guarantee for all time that the Report-Designer receives all the friendly attention from our developers that it deserves.


    BIRT seems to be aimed exclusively to J2EE environments. The download size of 100MB for the Runtime is almost prohibitive for client side deployments (or it would give the term "Fat client" a totally new meaning). BIRT ships with a Web-Viewer, but not with a Report-Viewer for Swing or SWT. (At least I was not able to get a single reference for either one out of Google.) Therefore BIRT is no longer an option if you are developing desktop applications.

    BIRT requires you to store the report definitions on the local disk. You cannot use any other loading mechanism and therefore it does not integrate well into non-disk repositories. During the report generation, it spits out a lot of temporary files, that fill your disk (and eventually get deleted, if everything goes well. If not, then please clean the temp dir from time to time.)

    The Pentaho Reporting Engine, on the other hand, has a deployment size of about 6 MB. It does not require anything beyond a JDK 1.2.2. It does not fill your temp-directories with garbage. It does not expect anything than some memory and it is fine with that. Where your report-definitions come from or where the content goes into is of little concern for the engine. You can use the local filesystem, but by no means would be assume that there even is a file-system. All reporting activities happen in memory with no need to swap anything to disk and anything beyond the default memory will be happily used by the engine for caches, but the engine is written in a way to work even under minimalistic conditions and with no assumptions about where it runs.

    The Pentaho Engine started with the goal to be a lightweight embeddable reporting engine. Therefore we emphasize on being easy to integrate and not trying to dictate details of the runtime environment. As a extremely lightweight engine aimed for lower range systems, we have a long tradition of being CPU and memory efficient. For a small-scale engine it is easy to scale up, as dont refuse to run fast on fast CPUs. But can BIRT survive down in the low-range systems where we feel happy today?

    BIRT, like our reporting engine, provides a rich set of extension APIs. However, while the Pentaho Engine concentrates on simplicity and tries to reuse as much of the JDK as possible, the BIRT APIs end in large frameworks. Thats great if you are a framework developer, but no longer funny if you need to bring your custom data into the project. BIRTs Open-Data-Access API is nothing you implement in five minutes, while our engine is happy as long as you know how to return a Swing-TableModel.

    The layouting model of BIRT is geared towards documents, so it provides you with high level structures like Tables and Lists. However, the document oriented approach is not pixel perfect, therefore if you have to replicate a existing report or form as exactly as possible, BIRT is not a good choice. On the other hand, BIRT's document approach saves you from dealing with a lot of manual layout work, so if all your reports are expressable as documents, BIRT's model might be a great choice.

    Pentaho Reporting uses a totally different approach when it comes to defining report layouts. We provide you with a canvas, where you place your report-elements freely. This is great for replicating existing reports, but the freedom to place elements anywhere can be cumbersome if all you need is a tabular report.

    BIRT also offers a Canvas mode, but its translation into HTML or Excel-Tables is a little bit adventerous. It doesnt even come close to out highly optimized table-exporter. However, as BIRT concentrates on document-structures anyway, they have no real need for a good table exporter. If they want tables, they declare table elements.


    Of course: I'm biased as I spent a couple of years developing the Pentaho Reporting Engine. But in all that time, BIRT never showed up as a better reporting engine, as this heavy-weight engine seems to feed a niche-market of ready-to-run J2EE deployments. But once you need tight integration with your existing applications, the ready to run appeal fades away and then you need a different set of capabilities.
    Get the latest news and tips and tricks for Pentaho Reporting at the Pentaho Reporting Blog.

  3. #3
    Join Date
    Apr 2008
    Posts
    9

    Default

    Quote Originally Posted by Taqua View Post
    BIRT requires you to store the report definitions on the local disk. You cannot use any other loading mechanism and therefore it does not integrate well into non-disk repositories.
    This isn't true. You can use IReportEngine.openReportDesign(InputStream).

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 - 2019 Hitachi Vantara Corporation. All Rights Reserved.