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.
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.
With the advent of Java 11, the common consumer JRE is 3 whole feature releases behind. Would it not make sense to update by now, or does Oracle just intend for developers to set their source compatibility to Java 8?
This is because they're switching to a long-term service (for stability) and non-long-term-service (for new features) model for support timelines. Java 8 was the previous LTS version, so for stability reasons, it has been the default version pushed on people and not 9 or 10.
Java 11 is their very latest LTS version, but it just came out. I'm assuming they want to iron out any found bugs before recommending it more generally, but you'd have to ask Oracle to find out for sure.
I have a doubt about java upgrading
I have applications running in java 6, for example.
And I wanto to upgrade my java to a 7 or 8
My doubt is: What is the best way to upgrade mi current java version?
Or how can I do it?
This applications currently are productive, so this means I has to upgrade the java version witouth affectate it.
I'm very confused about this, hope you can help me
There's only one way to do it:
Upgrade the JVM
Recompile the code and fix any errors that the JVM complains about.
Regression test the code running under the new JVM and make sure the functionality is unchanged.
Take the opportunity to see if there are any advantages to adding new features (e.g. java.time package, lambdas, java.util.function package, etc.)
No one should be running on any JVM other than 8 or 9. JDKs older than 8 have passed the end of their support lives. They are not getting any more security patches.
You are making the excuse that everyone tries when faced with currency issues: "The code is working fine. Why change it?"
Unfortunately there's a price to falling behind.
I'd advise you to upgrade as soon as possible. Stop the excuses.
JDK 9 is the current version. Current or current-1 is usually acceptable; current-3 is not.
Once the JDK9 is Generally available can we continuously blocked the upgrade?
IF yes until when?
Currently we have an application using java pluggins, we are still working on the equivalent web application. As per news the target date for the JDK9 is March 23.
If by March 23 we are still not done can we block the JDK9 upgrade?
You can still download and install Java 5, if you really want. Nothing will compel you to upgrade to Java 9, however Oracle will eventually end support for Java 8, at which point you'll stop getting security updates. The last public release of Java 7 was almost two years ago, for example. Any improvements to the JVM or JDK since then are only available in Java 8.
Even if you don't care about security(?!?!?) the correctness of your application will also start to falter - JDK releases contain updated timezone information, among other data that changes over time.
In general, it's going to be a lot better for you to work to solve your problem a different way that's future compatible, than to stick to legacy features that are no longer supported.
I am a bit worried about something and no matter how much i searched i could not find something or i could not search properly.
I have an application that runs on java 6 SE. Oracle mentions in the website that they will drop the Java 6 SE Deployment in June 2017. So that leaves me with a question. Will my application still run after the Java 6 end or will it crash?
Deployment Technology for Java SE 6 will be available until Jun 2017
Mentioned here
Will my application still run after the Java 6 end or will it crash?
It will continue to run.
If a user downloads and installs a Java 6 JRE / JDK, your application will run as before.
If a user has Java 7, Java 8, Java 9 .... etcetera, your application will run on those platforms provided that it is properly written. Things that might cause it to break include:
dependencies on restricted "internal" classes that have been changed or removed in a later release,
incorrectly written multi-threaded code that breaks due to platform differences,
a tiny number of documented incompatibilities, and
dependencies on 3rd-party libraries that have not been ported.
However ....
You ought to take the time to port your application to run on the latest version of Java. This is probably just a matter of compiling the codebase on the newer / newest Java JDK, and then running all of your unit and system tests. (But if you have extensive dependencies on old libraries that are no longer being maintained, then you may have a problem ...)
If you don't do this, your application is liable to become problematic for users who won't or cannot install an out-of-date (and probably insecure!) version of Java on their systems.
This is even more important for applications that depend on web deployment and Java plugins for browsers.
Yes. No. Maybe.
If you continue to use old JVM nothing will changes. Except you won't get bugfixes and security patches.
If you migrate to new JVM then in theory all should be fine (Java declare backward compatibility), but sometimes problems may occur. That's why you need to test you application with new JVM before you go into production.
As mentioned by some of the others, yes your application will still work. It just means they will be done supporting it.
Oracle’s poor wording is ambiguous
To answer the specific part of your question, let's look at the text of the Oracle page, Oracle Java SE Support Roadmap (retrieved 2016-10).
Support of Deployment Technology
The web deployment technology, consisting of the Java Plugin and Web Start technologies, has a shorter support lifecycle. For all major releases of Java SE starting with Java SE 7, Oracle provides five (5) years of Premier Support for these technologies. Extended Support is not available for the deployment stack. See the Oracle Lifetime Support Policy for details.
Deployment Technology for Java SE 6 will be available until Jun 2017.
This says that for (a) the Java Plugin for Java applet and for (b) Java Web Start specifically you cannot purchase additional technical support from Oracle beyond 2017-06. Other Oracle extended support contracts running beyond that date do not include technical support for the Java SE 6 version of this pair of deployment technologies.
That last sentence is poorly worded. I believe we can assume it should have begun with “Technical support for”. I understand the cause for your Question here.
As others have said, Oracle has never time-bombed any Java technology product nor have they ever announced any plans for doing so.
Oracle support for the plugin and for applets is practically moot as various operating systems and web browsers in recent years have been limiting or ending their support for Java applets due to security vulnerabilities. Java Web Start remains a viable platform for distributing local Java apps, though I recommend such apps move to later versions of Java.