Why is it that I can't keep the latest version of Java, that I have to downgrade to Java 8 for almost all Apache Projects?
Is Java not backward compatible?
A program compiled to ByteCode on a older JDK should be run perfectly well on the JVM of a newer JDK.
Why is it that I have to go through the pains of building from source?
I thought this was one of the things that Java was supposed to overcome!
This problem is not exclusive to Apache projects. With the newer Java Versions it's not so much about 'understanding the older code' but more about 'am I allowed to use these features the old way' (modularization).
In some cases the older code also uses features that are just not part of the latest JDK any more (e.g. removal of JEE Modules). I'd recommend to read Oracles Migation Guide for more on this topic.
For (bigger) projects the Migration to >Java8 is something that needs to be planned and organized and takes a lot of time.
If I am not mistaken older versions of Java e.g. Oracle Forms running on 1.4, will still work, when ran in JVM 8.
But my question is related to Java Accessibility. I am struggling to make the Oracle Forms expose its elements. Therefore I am wondering whether it could be that the JRE which is running Oracle Forms 1.4 would require me to have Java Access Bridge for 1.4?
I am not sure how this part works any assistance is greatly appreciated!
Found an answer from https://docs.oracle.com/javase/7/docs/technotes/guides/access/enable_and_test.html
In case there are many versions of Java used in the technology stack, it is advisable to just go through them all and disabling different versions.
In my case, unfortunately, the application is built in a way that Accessibility is not supported.
I was using the jxls-2 library, but when I finish my work I've seen that I can't use it with my java version (java 6.22). Do you know if I can solve my problem without change my code? Or in the other side, if I decide to use a jxls older version, I'd have problems with my java version?
That's my first question, by this reason, I'm so sorry if I don't ask correctly.
Thank you!
If you cannot update to Java 7 or to Java 8 (strongly recommended) you have two options:
Use older Jxls 1.x version. Depending on your use case Jxls 1.x may be enough for you.
Checkout the source code for Jxls-2 and change the source/target java version in Maven compiler plugin from Java 7 to Java 6. Possibly you will need to do some minor code changes to compile it but it may also work out of the box.
Our desktop-only product at work has been using JDK 1.4.2 until now (also 1.4.2 JRE shipped with product). I am trying to convince the management to let us upgrade to a newer version in order to get the performance, API/features and developer comfort benefits.
Since 1.5 has reached EOL transition, I'm I thinking of the upgrade to 1.6.0_10 directly (update 10 chosen as it is a major one).
In terms of code, all compile errors are just variable names called enum which I have renamed and the product works fine.
The question is
Whether this upgrade is recommended/fine i.e. skipping 1.5 ? are there any catches
If yes then should I upgrade to 1.6u10 or the latest 1.6 available ?
Thanks
I would say if you are going to do the upgrade then go for whatever the latest update is. You may actually get some free performance gains going with 1.6, I know some JVM improvements have been made since 1.4.
In general, Java is fairly good in being backwards compatible.
In case there is a need to find out what has changed in the Java platform from 1.4 to 6, the following is a list of changes that Sun has listed for each release:
Java 5: New Features and Enhancements
Java 6: Features and Enhancements
There's always a possibility that any specific release may contain a bug affecting you, or that your code depends on some unspecified behaviour of standard API classes that has since changed, but in general, upgrading to the latest Java release is recommended and relatively painless. You should of course test the product extensively on the new JRE.
It's Java, it's not a dirty scripting language which changes its syntactic, its grammar, and its API every minor release.
Backward compatibility is one of the major features of Java.
Just did it (Swing app) from 1.3 to 1.6 :)
Works (according to UAT testing) perfectly OK (except some changes required for awt UI). PTE shows some memory consumption reduction (not much), and the server side works somewhat faster (I tend to think it's due to GC improvements and string intern()).
In any case, you have to do it because of EOL, and 1.6 is not much different from 1.5. So I'd say 1.6 definitely.
Whether this upgrade is recommended/fine i.e. skipping 1.5 ? Are there any catches
I think it's a good idea to skip 1.5 and go directly to 1.6 and there is absolutely no requirement that forces you to go through 1.5.
If yes then should I upgrade to 1.6u10 or the latest 1.6 available ?
I'd go for the latest. Actually, I think 1.6u16 is the current major release.
I would recommend upgrading to Java 6 over 1.5. As there would already be a need to test your app against the new JRE regardless of the version you choose, you may as well take advantage of this opportunity. Instead of incrementing your upgrade twice (once for 1.5 and later for 1.6) and requiring a test cycle twice, you can get it out of the way once. While you are at it, upgrading to the most recent version available would be perfectly fine.
We recently upgraded our Swing-application (lots of drag and drop) from 1.4 to 1.6 to get the concurrent facilities, and we have not seen a single issue which is due to Java itself. We also want to go to the Nimbus Look and Feel since the Windows look and feel doesn't look and feel like Windows.
The killer feature you should show your boss, is how to attach to the application using jvisualvm to introspect the running program in case of issues.
Swing apps can definitely have issues version to version. We have had issues every upgrade (1.3 to 1.4 and 1.4 to 1.5 and we stuck our toe into 1.6 - and more issues). However, there is no reason to spend time on 1.5. Go straight to 1.6, the latest release, you won't be saving any time by going to 1.5, you will just spend a bunch of time testing on 1.5 and then do it again at some point in the future for 1.6. Much more economical to jump to 1.6.
A lot of minor revisions fix issues, so sticking to 1.6_u10 is just inviting issues. u10 was a big upgrade (unlike its name implies) as far as Swing is concerned, and several of the releases after that addressed issues that came to light after u10 was released.
A list of potential compatibility problems is provided by Sun: http://java.sun.com/j2se/1.5.0/compatibility.html.
Have you encountered other problems when running/testing old-1.4-applications against Java 5 (e.g. A specific library no longer working ....)?
The Java 1.5.0 deprecated list may be of help.
You may discover an alternative list of backward compatibility problems in all versions of JDK including 1.4 and 1.5 at the following web-sites:
JDK-Results at Japitools Home Page:
In an ideal world each JDK version would be perfectly backward compatible with the one before. As the following table shows, in reality this is not the case ...
Test results for JDK at Java Upstream Tracker:
This service is aimed at monitoring and analyzing Java libraries development. It is looking for new releases of various libraries and checking them for backward binary and source compatibility ...
These results were obtained by static analysis tools and can be used together with the official compatibility notes (Incompatibilities in J2SE 5.0 since 1.4.2 from Sun/Oracle).
In general, code that runs under 1.4 should work under 1.5. I don't think any previously deprecated methods were even removed. However, bugs are fixed between releases and you might get some slightly different behavior if your application was written in such a way that depended on the bug (I have encountered this with a Swing application).