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.
Related
I'm working in a company that has many projects in Java 8. Those projects are valued as old, and our team would like to upgrade the version. However, we need valid points in order to unlock the situation.
Those projects are using Spring and Hibernate (if it's ever useful).
What factual points could we give to our company to upgrade the versions, if any factual points there is ?
Examples of useful, valid points would be:
Security improvements
Performances improvements
New libraries or framework updates which could ease the development process
New possibilites/features with an upgraded Java Version
...
Possibly, backed up with documentation or links to useful resources.
old Java version will eventually stop getting new security fixes, which will make your software more vulnerable
using an old software stack will make it harder to find new developers willing to work on your software. Java 8 probably isn't too old for that yet, but in a few years that will be similar to finding "Java 1.4 developers" right now.
using an old software stack can severely limit your selection of useful third-party libraries and/or tools. A given library that you really need might require a more recent Java version or (possibly even worse) a library that you already use increases it's Java version requirement with a new major release (leaving you stuck with an old Java version and an old software version that might be missing important bug fixes).
There are several advantages from switching to newer Java versions, which are probably not the main reason to switch, but could be considered additional incentives:
newer JDK implementations might have better optimizations (in JIT and Garbage Collection mostly) that might help you get better performance from existing hardware (or reduce your cloud computing costs)
newer Java versions tend to have support for more modern technology, like the newest TLS versions and cryptographic algorithms which can help you data more secure, if you use them correctly.
new language features might improve your code style, which makes your developers happier, which means less churn which saves money on hiring new developers.
The reason to jump from 8 to 11 is the support of Oracle (or other implementation).
You can find the roadmap of Oracle here. For Java8 you are safe up to March 2022 for the premier support and extended support to December 2030. For Amazon Corretto they will provide free support and updates for version 8 to (at least) June 2026.
So the major reason to update your JVM version is support and updates. You still have time to update your version but you also have to wait for you 3rd party library to deliver compatibility with Java 11.
If you wonder why from 8 to 11 and not to 9 or 10, the reason is that 9 and 10 are not marked as LTS (Long Time Support) meaning that the different implementation won't provide any support and updates (or not for long) for those version when the next one is release.
Security updates for Oracle Java 8 are only provided via enterprise licenses and you could save that amount by using newer stable releases.
Apart from that, using newer versions also guarantee better integration with modern JVM tools, like up-to-date build tools.
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.
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).