New Java versions are an exciting event. In addition to the bug fixes (and new bugs!) in the JVM, a Java version often adds new methods and classes in the new release. This is generally a good thing because the Java language can grow and develop. But what about backwards compatability?
If you only use the latest version of Java (and you have no external clients) this is not a problem you need to worry about. But if you have customers, you need to support older versions of Java. For example, we support Java 5 and above, so we will not want to use and methods or classes added in Java 6 or Java 7.
Which version you choose to support is a tradeoff – Java 7 would vastly reduce your potential market while Java 1.0 would be silly. Java 5 seems a reasonable compromise as it has been out since 2006 (and we may well make it Java 6 later this year so we can make more use of JavaFx).
In theory backwards compatibility is simply a matter of setting the compatibility level in your IDE. In practise we have found that this does not work 🙁
So our solution is to add an additional stage to our continuous testing. As part of our Java testing we always perform a build against Java 5. This week alone, it has picked up 2 different cases of Java 6 code we had accidentally added but the IDE test had missed. The Java 5 build test failed until we fixed the code.
This is the best way we have found to preserve your backward compatibility. Once written it is transparent, fast and effective! Do you have any experiences with trying to support backwards compatibility?
Do you need to work with PDF or Image Files in Java?
|Convert PDF to HTML5 or SVG||Convert AcroForms and XFA to HTML5|
|Java PDF SDK for working with PDF files||Java Image SDK for working with Image files|