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.
Related
I want to download JRE 1.7.0_131-b31 as i read its support TLSv1.2 by default
TLSv1.2 and TLSv1.1 are now enabled by default on the TLS client
end-points. This is similar behavior to what already happens in JDK 8
releases.
But Oracle site showing latest version of jdk-7u80 and after this release no other Java 7 version available.
Is this because ,user have to buy license/paid version ?
These version not available for individual developer ?
Why Java 7 release not available after jdk-7u80?
Because of Oracle business reasons. Free public support ended in April 2015.
(Backporting patches and so on requires a team of people. That costs money. Oracle is a commercial enterprise. And other reasons.)
Is this because user have to buy license/paid version ?
Yes. You need an Extended Support Contract to use versions after 7u80
These version not available for individual developer ?
No.
If you or your client requires Java 7 with TLSv1.1 and later, your options are:
Upgrade to Java 8 or (better) 11. This is the best option.
Use a 3rd-party JCE provider (such as BouncyCastle) that still supports Java 7.
Pay Oracle for an "Extended Support" support contract.
Point out to the client that this is the cost of them not investing the money / effort in keeping their Java application stack up with the latest versions.
If they are still using old libraries and applications that are permanently stuck at Java 7, they should be planning to discard or replace them. Yes it is painful, but it is more painful in the long term if they don't. (In July 2022, even "Extended Support" ends for Java 7. After that, even security fixes will stop.)
Note that Java 8 is due to reach end of life fairly soon too. Indeed, free support for commercial use has already ceased for Oracle Java 8. You / they should really be aiming to get to Java 11 ASAP.
I would also suggest that if they want you to continue supporting them on Java 7, they should be (in effect) paying for the Java support contract that you need to do your job. Renegotiate your billing rate, or whatever.
For more information on Java versions, end of life, and end of support; see:
https://en.wikipedia.org/wiki/Java_version_history
https://www.oracle.com/java/technologies/java-se-support-roadmap.html
My understanding from "Do you have to pay to use Java?" of Java programming language Free
is that I can go for OpenJDK(version 11) build provided I don't need LTS as both OpenJDK and commercial version are identical in terms of features. If I need to purchase LTS(Long term support) either I have to purchase support for OpenJDK or upgrade to same version of "commercial Oracle JDK build". Is that correct ?
Another question is why I need LTS ?
I think if we don't take LTS then any we don't get any support/patch for defects( or security patch). Right ?
I wrote a blog article discussing that topic in early 2019.
First, as far as I know, the OpenJDK team does not offer any premium support.
Second, normally one goes to the LTS for longterm support, mainly security updates.
Third, Oracle will only hand over the code for the LTS version to the OpenJDK team and only after the LTS has reached its end of life. This means that the OpenJDK community has to keep up with changes on their own.
Now to the topic on the JDKs being identical. They both pass the JCK and thus can be used as drop-in replacement for each other. The implementations, however, may vary.
There is a host of JDK providers, all with different support plans. Fact of the matter is, there is no free lunch. If one wants support, one has to pay.
A remark on your post: Please limit yourself to one question per post
OpenJDK is a free and open-source implementation of the Java Platform. The implementation is licensed under the GNU General Public License. You are free to use at any environment. But you won't get any kind of support from the Oracle and you've to rely on open communities support, later can be best than the OEM support some times.
LTS is a product life cycle management policy in which a stable release of software is maintained for a longer period of time than the standard edition. You get security updates for some good number of years.
Do you have to pay to use Java?
Answer is yes, Iff you use Oracle JDK for business, commercial, or production purposes.
Answer is No, if you use OpenJDK irrespective purpose or environment.
PS: this is all about licensing and it can change over a period of time.
LTS is supported for 3 years and will receive updates until it expires. When you use openjdk you need not pay for support or patches. I always go with LTS like java 11.
The non-LTS version will have newer features but they are short lived like 6 months. They don’t receive updates for long rather it is expected to upgrade to next version. Security patches are available on same version or next version.
If you don’t have a special usecase then open jdk is more than enough
Java releases are coming faster than expected do we need to migrate the code stuff which is old version to newer one to make it more performance based and upto date.
do we need to migrate the old java code base to latest version?
No.
Quite the opposite. You may decide to stick with deploying only the Long Term Support (LTS) (see Wikipedia) versions of Java. The promise: A version that will be actively supported for years with updates for critical bugs/issues but no new features or changes that might break existing deployments. The first such LTS version is scheduled for 2018-09, to be known as either Java 11 or 18.9 LTS (with year and month as release number).
Oracle has announced the changes in release cadences and support policies in late 2017 and again 2018-03. So it may take some more months until we know the exact nature of what releases are supported for how long by whom at what price.
In particular, you may want to avoid ever deploying Java 9 as it has had a brief life, with free-of-cost public updates from Oracle ending this month, 2018-03. By the way, Simon Ritter wrote about 109 New Features in JDK 10.
One of the core ideas behind the new regularly-scheduled “release train” plan is that hundreds of finished features were held up for years waiting on the Java 9 release. In a project as wide and diverse as the Java platform, it makes much more sense to ship whatever features are deemed ready every quarter or semester. If you find such features useful for your future deployments, you may choose to adopt that release. Or you choose to limit yourself to mere experimentation, while waiting for a future LTS version with those features.
more performance based
Future releases may or may not have improvements related to performance. And those improvements may or may not benefit your particular deployments. You will have to make a choice at that time about whether any of the particular improvements are worth migrating any of your particular deployments.
By the way, regarding performance, work is underway to make alternate garbage collector implementations easier to build and deploy. You may wish to keep your eye on developments there.
and upto date
As discussed above, “being up-to-date” is a choice you will have to make release-by-release. Making that choice will be easier as the list of changes to each release will be shorter and therefor easier to understand, digest, and test.
While Oracle and the community are committing to make each release fully qualified as stable and definitely not a “beta” disguised as an official release, change always brings some degree of risk. You may decide to stick with LTS versions to avoid the changes.
Early access
You can still access pre-release versions of Java. At this moment with Java 9 being the official release, Java 10 release candidate is available for trial. And JDK 11 has early access builds available.
Resources
See the official Oracle Java SE Support Roadmap. And be aware that Oracle has announced and confirmed that it is busily working to make their Oracle Java implementation virtually identical to OpenJDK, including contributing some of their add-on tools that are currently commercial products.
Also, you may want to consider alternate sources of implementation and support for Java. For example: Azul Systems with Zing & Zulu, IBM/Eclipse with OpenJ9, RedHat, and so on.
There is no need to do it, but the question is whether the rest of your code base is distributed in e.g. 1.8 compliant.
Having 1.8 is mostly a comfort for developers, keeping old code base is fine. But I've also been revisiting a few old classes dealing with e.g. Process creation and concurrency basic bricks and I'm very happy to have done so.
So do it where you clearly gain for doing it, iff. you think you can expect such recent JRE from your clients. If you already have recent JRE dependency, do some refactoring as code is reused and you revisit old APIs, if some new feature clearly kills your old solution, but not systematically is my advice.
Biggest issue with upping Java version is clients can't run newer versions, otherwise old code runs just fine on newer JRE.
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.