About moving JasperReports to Java 5.0

[Teodor Danciu]

Hello,

 

I'm starting this debate about the opportunity to break JasperReports compatibility to Java 1.4 and move it to Java 5.0.

 

I won't talk about the advantages of using the new language features such as generics and type enums, which we are particular interested in, nor about the future of Java 1.4, which has reached End Of Life more than a year ago:

http://java.sun.com/j2se/1.4.2/

 

The question is: How many people are still using Java 1.4 in production and how many of them would need to upgrade JasperReports in the future, without upgrading the JVM as well?

 

Giving that many third party libraries that JasperReports depends on, have alredy moved to Java 5.0, we expect that the advantage of being compatible with Java 1.4 will no longer be an advantage, but rather keep us anchored in the past.

 

Moving to Java 5.0 would give us the opportunity to make some API refactoring and improvements. This in turn, would raise the question of keeping backward compatiblity of compiled report templates (*.jasper files).

With every new release, JasperReports guaranteed compatibility of older compiled *.jasper files.
This means that if people had compiled report files in their applications, a newer version of JR guaranteed they would still work.
If this was not the case, then it was a bug, and we did not have such bugs very often, since this upgrade policy was put in place in JR 1.2.0, released in February 2006.

Prior to JR 1.2.0, it was understood that people had to recompile their JRXMLs, if they upgrade JR.
So in the last 4 years, JR upgrade was guaranteed to be painless.

However, in order to maintain this compatibility, we have wrote custom deserialization code, for our object model, every time we made a change in the model.
I'm currently working on some model refactoring which includes the use of type enums, especially if we are to move to Java 5.0.
Keeping compatibility of *.jasper files would require a lot of deserialization code.

But if we decide that with version 3.8.x, older *.jasper files are no longer compatible and they need to be recompiled from source JRXML, we would give ourselves the once in 4 years opportunity to clean the library from all the custom deserialization code. We would be starting from fresh, in this sense.
Guaranteed compatibility policy will continue to exist, but we would have something like a fresh start, that would allow us to guarantee compatibility from that point onward for another 4 years or more.

Basically I'm asking for a break here, to allow us to do some code cleanup.

Note that in the majority of cases, the upgrade would still be easy, because we have Ant tasks for compiling JRXMLs, and in the last JR 3.7.1 release we even added an Ant task for decompiling *.jasper files into JRXML files.
So users that would encouter the incompatibility problem at upgrade time, can either recompile the reports from JRXML source, and if they no longer have it, they can decompile the *.jasper files and regenerate their source and then compile them back.


For JasperServer, with its cached precompiled reports, we can consider the clearing of the cache as part of the upgrade procedure, or we could intercept the incompatibility exception and trigger a recompilation of the report (in case it does not already work this way). The end users will not even notice compatibility was broken, because the reports are recompiled automatically if needed.

 

Thank you,

Teodor

 

[sonideft]

I'd say go for it and don't stop at Java 5.0. Go to Java 6 and use everything you can from it, including logging, collections, generics and so on. I recently re-platformed a java app I had working with JasperReports on Java 1.4 and moved it to a NetBeans environment on Java 6. The experience was not easy nor pleasant. I ended up downloading all of JasperReports and compiling as a separate module in the project. Eventually I satisfied most of the library dependencies only to find that Java 6 logging is not really that compatible with commons.logging. I modified all the sourcecode to use Java 6 logging and was finally able to see the error messages that I should have been seeing.

I can see where others could have the same frustration and loss of time. I could see where very simple apps would not have the problem I've had, but I rely on other libraries as well; of which none have all these same old dependencies.

I vote for you to go for it, refactor everything and clean things up. One thing I noticed, while working through report errors, is that there are several routines which generate and/or re-throw exceptions. By the time a routine catches the exception and reports on it is usually too far away from the issue to be of any help at all. Fixing that would be a nice clean-up. The alternative is stepping through many lines of code to see where the real issue is created. Not fun.

Steve

[jtravies]

I agree, go all the way to JDK 6, I dont know how many people rely on .jasper file? I dont, we inside the application stored .jrxml in the Database (they are small) we compiled it the first time and cached the .jasper. Long life to the XML!

[venture]

I vote to go all the way to Java 6. A major version upgrade for sure for JR. And while you are at it ensure that it works with the likes of current OS such as Win7 and MAc osX etc

[kenyoungsolutionary.com]

 The change would benefit new development.   JDK 1.6 would be my vote.

[christiaan_se]

I agree, move to Java 6. For a product / developer the choice is straightforward I think, if you don't want to upgrade the jre version, you shouldn't upgrade your jasper version.

[urlgrrrl]

From my experience, customers who are still on Java 1.4 are not investing in the time to upgrade dependent libraries such as JasperReports. Updating JR to 1.5, at least, or 1.6, preferably, would be terrific and is long overdue.

[dnvsrikanth]

I think it be beneficial to upgrade to 1.6 to use the new features that were introduced in Java 1.6. It will provide us a chance to use the new features introduced in jdk 1.6

[Teodor Danciu]

Hi,

 

Thank you all for your feedback.

 

For now, we upgrade to Java 5.0 and keep backward compatibility of *.jasper files for minimum/no disruption to our existing user base.

Refactoring is an ongoing process and we'll continue to improve our product and keep it up to date. We'll see if at some point, it would be better us to go even further and upgrade to Java 6.

 

Thank you,

Teodor