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).
Related
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.
Since the release of Java 8, I found myself slowly becoming dependent on Java 8-specific features (ex. lambda statements) on a library project that I have just started.
I have seen many other projects which, to this day, still build against Java 7, or even Java 6, causing me to second-guess myself.
Is it a good idea to immediately start building against the newest version of Java, or should I still use older versions?
Note that unlike those other projects that have started back when Java 6/7 was the newest version, mine was started recently when Java 8 is the newest.
There are two reasons I can think of that would require staying with a pre-Java 8 JVM:
You are writing a library that is being used by a large group of people outside your organization who are still stuck on a pre-Java 8 JVM. If you use the latest and greatest JVM, they won't be able to use your product anymore.
You are dependent on a 3rd party library that has not upgraded to Java 8 and breaks on Java 8.
Since you mentioned this is a new project, #1 is unlikely. Even if you plan on having external users, if it's a new project, requiring the latest version of the JVM isn't really an issue.
Number 2 is also getting more and more unlikely as the more popular 3rd party libraries have released updates to work on Java 8. Even the few stragglers are usually OK working on Java 8. For example I use an ancient version of hibernate with Java 8. I just don't use any Java 8 features in any mapped fields/entities.
Java 8 denotes a major change to the language since Java 5 (or perhaps its inception). If you are targeting specifically the changed language parts (which I guess you claim) then making it usable only by Java 8+ runtime makes sense.
When Java 5 occurred 10 years ago and you wanted to use all the new features introduced at the time (e.g. foreach statement, Enums etc.) into your own library development, what would you have done? I believe you would have made your library require Java 5 at the minimum. If you agree with that, then that (sound) logic applies consistently to your present situation as well.
For server side application, possibly a version or two prior to the current version as suggested by EJP.
On the client side however, I don't see any point in trying to support older Java versions. The JRE has been auto-updating since at least Java 6. It has gotten to the point where Java Web Start launched applications cannot specify an earlier than current JRE. Or rather, it can specify any JRE it chooses in the launch file, but that will be ignored in favor of the latest version installed on the user's computer.
I need a little clarification regarding JRE. Is it downward compatible? I mean if I develop an application using java5 and if the target has the latest java6 will my application be able to run?
unless you are using the incompatibilities listed in sun documents Compatibility
Yes, provided you're not using really old deprecated APIs (like, ones deprecated in v1.1)...and maybe even then.
That's APIs. The bytecode is absolutely forward-compatible. It's been revised a couple of times, but always in a forward-compatible way. So code compiled with JDK 1.4 runs fine in the latest; but code compiled with the latest may not run with an older JVM.
Yes - Java's very good about that.
I'm writing about it here java backwards compatibility.
The bytecodes generated can be run in future releases of jvm however the compiler is not backward compatible as bytecodes generated with higher version won't run in older version. This is a good read on Sun site here
As I'm sitting here modifying PircBot, I've just noticed that the entire backend was written to support Java 1.1. It has a custom queue implementation, uses hash tables, custom producer/consumer implementations based on wait() and notify() signaling, etc. Even Commons-lang lacks any support for things that Java 5 brings to the table like generics. You can pull a bunch of other examples of very popular frameworks that try as hard as they can to support 1.1.
My question is why? Why are certain parts of the Java community refusing to support new versions? I go by this theory: Old versions use older versions of frameworks and older JVMs, newer versions use upgraded frameworks and JVMs. You upgrade everything with the software.
Now I can partially understand people still running Java 1.5, but 1.1? If your running anything before that then your obviously not upgrading the JVM because of stupid policies/scared of the unkown, and therefor aren't going to upgrade to newer versions of software. So why are we still supporting them?
On a related note, if you are writing a new framework should you support anything <1.5? Should you try forking existing frameworks, upgrading it to 1.5, then talk to the maintainers about using it?
Much more specific discussions (this is about support in general):
Is there still a good reason to support JDK 1.4?
Dropping support for JRE 1.3
Because its easy! From Java 1.1 to Java 1.4 just tiny language features were introduced (strictfp for example). So why restrict yourself if you don't need to. So lets say you write a StringUtil class or you parse Word files then is simply does't matter. Just starting with Java 5 you have language improvement and from Java 1.0 to Java 1.1 of course inner classes.
This is just for the language and not so much for the libraries. There are interesting additions of course.
I think the most common reason is, that new features introduced in later versions are not used anyway. I mean, if a library does not use new features like generics or advanced concurrency features, there is no compatibility overhead at all.
Backward compatability?
Changing the level of JVM support, should warrant a major release. I.e. version 1.x goes to 2.x to indicate this.
Also I believe to have read that to get most coverage in mobile phones, you need to target 1.1. That may be old though.
I know of at least one commercial enterprise that decided they would never move beyond 1.1 so that they could run forever on both java JVMS and .NET with the same source code.
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.