JasperReports vs. BIRT

[byteryder]

Thought others might benefit from my recent experiences.  I have an eclipse RCP desktop application that has a JDBC database as its data source.  Reporting is done with JasperReports (JR) and swtJasperViewer.  A couple of years ago, selecting JR over BIRT was easy because BIRT was pretty rudimentary.  Since then, BIRT has improved greatly, but JR has also been refined.  I've recently revised my app and considered switching to BIRT.  I read the tutorials and one of the books (two are now available), played with BIRT, and decided to keep JR.  Here's why.

• BIRT documentation has improved greatly, to the point it is now usable.  JR documentation,whiile not great, is sufficient.  The Heffelfinger book is relevant to the current version and is helpful.  In this area, I judge BIRT and JR tied.
• Both have GUI report designers.  JR's iReport is cross-platform compatible while the BIRT standalone designer is available only for Windows; an interesting choice by the open-source eclipse project.  To use the BIRT report designer in Linux, I had to download a full eclipse SDK.  Both work well, so I think this is also a tie.
• Both have viewers that can be incorporated into an RCP application.  The BIRT viewer has basic functionality but swtJasperViewer has a better "print" feature and the zoom feature is very useful.  Definite edge to JR.
• The code to incorporate JR and swtJasperViewer into an RCP application is simple and straightforward.  BIRT is a bit more complicated.  The BIRT documentation focuses largely on incorporating it into a Web app, not a desktop app, so for this purpose it is really no better than the JR documentation.  Edge to JR.
• BIRT is now able to export to a couple more formats, including pdf, Excel, and Word 2003.  Again, an interesting choice by eclipse to go with these proprietary formats rather than open-source standards.  OpenOffice.org 3 Writer is able to read MS Word 2003 documents but I was not able to get it to read a Word 2003 file exported by BIRT that included a simple table.  This may well be due to Microsoft, which has been known to change standards without warning.  JR supports more formats, including pdf and rtf.  Definite edge to JR.

So, after experimenting with BIRT, I feel JR is still better for my type of project. 

[hf_monica]

I have to choose between these two report engines for a web app, so I connected both editors to my JDBC database to perform a very simple test (given an ID, retrieve a name, put it in a .pdf, and save this file on my Desktop): it took more than 20 seconds with JR, and not even 5 seconds with BIRT.

 

I'll run a few more complex tests to ensure that BIRT takes less time than JR to generate a report, but my mind is almost made up, even if BIRT generates PermGen exceptions more often that JasperReport on my Tomcat server.

 

 

[Teodor Danciu]

Hi,

 

I'm a bit courious about how you actually make those tests and in what environment.

20 seconds is a bit too much for what you said you have done (print a name in a PDF).

5 seconds to do the same thing is too much even for BIRT.

 

If I run any of JR samples from the project distribution package, they all run under 20 seconds and they clean, compile, fill and export to all formats documents that are several pages long.

 

When you make your tests, make sure you run the process several times in a loop, and time it each cycle and then remove the firts time and calculate the average of the rest of the cycles. The first running cycle gives you a false timing because it includes the time needed to load all the JARs.

Also, make sure you do not compile the JRXML file everytime, because normally, with JR, you only run compiled *.jasper files.

 

I'm not saying JR is definitely faster, but I would hate you pick a solution making irrelevant performance tests.

If you do want to decide based on these tests, you better make sure you do them correctly.

 

I hope this helps.
Teodor

 

[ceday]

 I have used JR some time ago :) 0.5x beta- 1.x

Actually it was quite good back then too :) 

Recently I have begun to search an updated java-based report engine to replace the reporting engine for the company I have been working sometime.

Most obvious ones were of course BIRT and JR.

BIRT has an advantage of being eclipse-based community but I think it is still immature and need some time.

There was not enough components when you compare with JR (complex components actually is not problem, they are considred as facility, but I couldnt actually see "line" component in BIRT which might be a critical one for some) (maybe it has now, dont know)

And I didnt really like the GUI design, grid-layout was only option or I just didnt know how to do otherwise.

(actually I would be a good future to be able to use grid-layout for some bands - not the whole report- in JR)

I think what missing in JR is an eclipse plugin, which they seem to be working on. ireport is a good one, but eclipse integration is a must for such a report engine.

 

 

 

[Teodor Danciu]

Hi,

 

Because Eclipse was mentioned several times in this thread, I just want to point out that the report designer that Cem was referring to is a new open source project called Jaspersoft Studio, which will be the future Eclipse-based designer for JasperReports:

 

http://jasperforge.org/projects/jaspersoftstudio

 

We are currently using small version numbers to indicate the project is still in Alpha state, but if you would actually try it, you would see that the visual designer part is almost complete, including crosstabs, list and table component designers. The project will soon pass into a second phase where development will concentrate on other tools such as expression editor, query editor, etc.

 

A new version (0.0.8) will be released this week, but I'm sure many of the Eclipse users will find the tool already productive.

 

Thank you,

Teodor

 

[hf_monica]

The previous tests were creating the .pdf locally, on my computer (not in a web browser or on a server). The first export was the only one that interested me, insofar as it would be the one creating a report client-side.

Anyway, I finally managed to export my report in the web browser thanks to Bruce Phillips's tutorial (http://www.brucephillips.name/blog/index.cfm/2008/7/12/Using-The-JasperReports-Struts2-Plugin-A-Main-Report-And-A-Subreport) and Fabiano Izabel's (http://www.devmedia.com.br/post-12129-Resolvendo-problemas-de-integracao-entre-Struts-2-1-6-e-JasperReports.html), and the generation takes not even one second.

Exit Birt!

 

 

[neozerabbit]

I made a prototype with Birt. For a  project I am benchmarking reporting solutions :

- Birt Open Source

- Birt Actuate

- Jasper

- Jasper + Aspose Cells

- Microstrategy (In progress)

- Oracle Business Intelligence Enterprise Edition. (in progress)

 

I tink Birt is more easy to use at first sight. The UI is very prowerfull and you have serveral ways for a same issue. Jasper is a less evident and have less options. Birt is unforunatly no mature  : it is a good tool but there some bug and problems that lead us to consider more Jasper. Physical architecture is closed and not friendly to surcharge contrary to Jasper. For exemple when you want to export as XLS in Jasper you onlu need to use ou program a jar for an Exporter wheras in Birt you have to write an Ecplise plug in, and put it in the Birt Engine to replace the emiter (seem to be that you cannot choose or define an Emitter / exporter and you have to replace the default emitter by yours).

The fact is that Jasper is more stable, open than birt but less "sexy" in its User Interface but it feed almost all cases you need to make a report and you can easily (modularity, no heavy dependance) write your own libe for specific treatment. Birt is is a bit like a Blackbox.

 Oracle Business Intelligence ... seems very prowerfull but it's heavy (need its own database, schema ++.etc) and can do reporting and analytics. It's a bit over, outside a simple need of reporting.

Microstrategy is on the same concept than Oracle Business Intelligence but it seems liter in installation, configuration and utilization.

 

Anthony