this is a follow up question about previously one Corda running on Java 9
We appreciate you have already started to work on Java 9 support. Are you able to tell us an estimated month for this completion? I believe all major organisation also have a red flag on all Java 8 application and require a plan for upgrade. Regarding bundling JRE into Corda, is this only going to happen for the Enterprise version? If so, for the open source version would you continue to support the latest version of Java?
Thanks in advance
Javier
We aim to be on the latest release of Java to take advantage of its latest capabilities. However, we don't have a specific timeframe for Java 9 support at this time. We will communicate this in the near future via Corda.net.
Related
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.
I have the existing codebase which runs on java6, but the current requirement is to upgrade the Java from java6 to java 7, Can anyone please let me know the steps, how can i upgrade it using eclipse(because i am using eclipse as IDE)?.
Upgrading code requires almost nothing, as Java 7 is backwards compatible with Java 6 except for a few things, mostly behavioral and in the standard library. And as said here, it should mostly just work:
What do I need to do?
Option 1 – “Just run”
Upgrading your eclipse project has been asked and answered several times, like here.
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.