Develop Reference

Security Updates with OpenJDK distribution [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
With changes in JDK licensing agreement from Oracle, companies are switching to OpenJDK.
My question is - which distribution of the OpenJDK would be a better choice? I am evaluating Oracle Open JDK and AdoptOpenJDK, and they both seems to be an idea choice.. However when it comes to support, Oracle OpenJDK is following a 6 month release cadence without any Long term support, however AdoptOpenJDK has LTS for Java version 8 and 11. So if I switch to Oracle OpenJDK, then I will have to follow the new release cadence to be up to data with security patches (I don't care much about the new features), however If I switch to AdoptOpenJDK, then I can go with one of their LTS version (11), and expect the new security patches will be applied to this version. My main concern is, I wanted to be up to date with Java security updates after switching to OpenJDK distribution.
References
https://www.reddit.com/r/java/comments/9hd97k/openjdk_vs_adoptopenjdk/
https://www.baeldung.com/oracle-jdk-vs-openjdk

tl;dr
If you want the most rapid release of critical security patches, pay for a support plan from a vendor such as Azul systems, BellSoft, Oracle, Pivotal, or Red Hat (IBM).
To better understand the current state of the world of Java releases, you really should study the document Java Is Still Free. Written by the Java Champions community of independent Java leaders and experts.
Details
With changes in JDK licensing agreement from Oracle, companies are switching to OpenJDK.
To be clear here, you may be referring to Oracle changing the terms to their Oracle JDK product to require a fee when used in production. That product is still free-of-cost for use in development, testing, and such.
My question is - which distribution of the OpenJDK would be a better choice?
Answering that depends on the criteria important to you. But you did not mention any criteria other than needing security updates rapidly (more on that below).
I am evaluating Oracle Open JDK and AdoptOpenJDK, and they both seems to be an idea choice..
Be clear on this: The OpenJDK project publishes source code only, not builds nor installers. Many vendors provide builds/installers based on the OpenJDK source code.
Oracle is one such vendor, providing three products:
Oracle JDK — their branded product requiring a fee for production use, with paid support available.
jdk.java.net — a build of OpenJDK without any fees and without any support.
GraalVM — a special product, a Java VM and JDK based on HotSpot/OpenJDK, implemented in Java, and supporting additional programming languages and execution modes, like ahead-of-time compilation of Java applications for fast startup and low memory footprint.
All three of these are based on OpenJDK source code. The first and last offer paid support programs.
Oracle has publicly declared their intent to keep Oracle JDK at feature-parity with OpenJDK. Oracle sponsors the OpenJDK project as part of that commitment. At the same time, Oracle reserves the right to rapidly release any critical security patch to their paying customers. They will eventually submit such patches to the OpenJDK project. But those submitted patches are likely to take more time to go through the OpenJDK process before being released.
AdoptOpenJDK is another vendor offering builds and installers of the OpenJDK source code base. So, again, any critical security patches may not reach the public free-of-charge as fast as a patch from another vendor to their paying customers.
Here is a flow chart I made to help guide you in your selection of a vendor for a Java implementation. You have a variety of choices, some with support options.
However when it comes to support, Oracle OpenJDK is following a 6 month release cadence without any Long term support, however AdoptOpenJDK has LTS for Java version 8 and 11.
I believe you are incorrect here. Oracle does maintain LTS updates to their Oracle JDK product for both Java 8 and Java 11, for some number of years to the public, and for additional years to their paying customers.
The Java community is much more cooperative in working together than you may understand. Every implementation of Java I know of is largely based on the OpenJDK project. The OpenJDK project is supported by Oracle, Apple, IBM, SAP, and possibly others. Amazon, Microsoft, and other companies contribute. The rapid release train and Long-Term Support (LTS) strategy has been embraced by the entire Java community.
Oracle has turned over stewardship of the LTS versions 8 and 11 to Red Hat, but Oracle continues to support them both. See the Oracle Java SE Support Roadmap for details.
So if I switch to Oracle OpenJDK, then I will have to follow the new release cadence to be up to data with security patches
Every Java implementation I know of is following along the same release cadence.
(I don't care much about the new features),
Then you should certainly stick to using only the LTS versions. Currently that would be Java 8 and Java 11.
If I switch to AdoptOpenJDK, then I can go with one of their LTS version (11), and expect the new security patches will be applied to this version.
You can expect security patches from any vendor providing a Java implementation. The question is how rapidly those patches will arrive to you.
My main concern is, I wanted to be up to date with Java security updates
Then I recommend you purchase a paid support plan from a reliable vendor. You have a choice of several. See the left side of the blue barrel in my diagram above.
If you think the chance of critical security vulnerability affecting you specifically is exceedingly low, or that you are likely to be able to mitigate such a vulnerability, then the cost of a support plan may not be worth it to you. In this case, you would wait for a newer free-of-cost release. You may be waiting longer than you would with a paid vendor.
after switching to OpenJDK distribution.
Every Java implementation I know of being distributed today is based on OpenJDK.
Here is another graphic listing possible motivations for choosing a particular vendor for your Java implementation.

Is there any OpenJDK that is fully free and will be available for commercial use

I just recently heard about the licensing for Oracle JDK, after trying to create a springboot app for a year. I wanted to find out if there are other alternative JDK which are free for production/commercial use, and if they are what is the certainty that it wouldnt be paid for after or that it would be in the market for long. My only alternative now is to rewrite my code in another language.

Yes, Java is still free
It is vital that you study: Java Is Still Free. Written by key members of the Java community, providing both a summary and all the gory details.
Guidance
The OpenJDK source code is available free-of-cost per its GNU GPL+linking exception license.
Several vendors provide releases based on that OpenJDK source code. They can do so free-of-cost or they can charge a fee or set other licensing terms, as long as they abide by the GNU GPL+linking exception licensing.
The Oracle JDK in latest versions has changed its licensing. It can no longer be used in production without a paid support plan. Contact Oracle for details. The Oracle JDK has converged to be at feature-parity with OpenJDK, with Oracle having contributed to OpenJDK even more of their formerly commercial parts such as Flight Recorder and Mission Control.
Other vendors also provide releases with commercial terms, for a product which may contain some OpenJDK code.
And some vendors such as Adoptium with their Eclipse Temurin product (formerly AdoptOpenJDK), Azul Systems with their Zulu product, and Amazon Web Services with their Corretto product, all provide builds of OpenJDK without payment required.
A release may or may not be labeled “Java”. If a vendor want their release to carry the branding “Java”, they must pass rigorous testing for compliance with the Java specifications and abide by Oracle’s terms for using their trademark.
Here is a flowchart that may help guide you in determining how and where to obtain Java 11. Important: This info may be incorrect. You are responsible for studying the details of the license under which you use any software.
(Note that the diagrams say "Adoptium", which is not a distribution, but instead the organization that produces the distribution called "Eclipse Temurin". See here for more info.)

All Oracle's OpenJDK's are free, in any environment. The issue arises when you use the Oracle JDK (not with the OpenJDK). Since they are functionally the same since Java 11, there is no need to switch languages.
More details here:
https://blog.jetbrains.com/idea/2018/09/using-java-11-in-production-important-things-to-know/

How can I get Java 11 run-time environment working since there is no more JRE 11 for download?

Java 11 does not come with a JRE for download, unlike past Java versions. I got an error "no java run-time environment" when running some Java-based software. To fix the problem, I had to install Java 8 JRE.
How can I get my PC to run Java 11 JRE given that there is no more JRE 11 to download?
I am using Windows 10.

The Answer by Stephen C is correct, and important.
Oracle no longer intends for end-users to be installing a JRE or a JDK. Java Applets in a browser and Java Web Start app delivery are both being phased out, leaving the end-user with no need for a JRE. Java-based apps are expected to bundle their own Java implementation. The only folks consciously installing a JDK will be developers & server-side sysadmins.
Important:
Understand clearly the nature of the OpenJDK project, as explained in Wikipedia
Read this white paper by Oracle of 2018-03, Java Client Roadmap Update
Read the white paper Java Is Still Free, authored by key members of the Java community.
Learn about:
Java Platform Module System
jlink (JEP 282)
jpackage (JEP 343)
Desktop apps are now expected to bundle their own Java runtime. Those tools listed above can create a very small runtime custom-fit to your particular app.
Here is a flowchart diagram that may help you finding and deciding amongst the various vendors providing a Java 11 implementation.
And a table mapping possible motivations or considerations leading to suggested vendors of Java.
Compatibility concerns
In the Comments, an question was raised, concern over compatibility issues between releases by various vendors.
Firstly, know that the OpenJDK project includes a vast suite of tests known as the OpenJDK Community Technology Compatibility Kit (TCK). Vendors are free to self-declare whether their release has passed those tests. These claims are not verified, and rely on the honor system. On my diagram above, I have check-marked "TCK" on the couple vendors I know have self-declared: Oracle JDK by Oracle & Zulu by Azul Systems.
All the products listed in the blue barrel area of my chart above are built almost directly on the OpenJDK source code. So generally, you should see virtually identical compatibility.
There are two areas of concern you might consider: Technology differences, and schedule of updates/patches.
As for technology differences, vendors using the OpenJDK project can ship with either the HotSpot engine or the OpenJ9 engine. These will differ on performance (faster/slower startup versus overall speed, more/less memory), but their behavior in terms of complying with the Java specifications should be identical. They could differ, and certainly either might present a flaw (that likely would be soon fixed) that the other lacked. Personally, I would not be concerned by this, but I mention it for completeness.
Another technology difference is the different kind of JVM used by Zing by Azul Systems and GraalVM by Oracle. Either of these might differ in some way from each other or from the other products, because they intentionally have a different kind of JVM implementation, to offer special features. But given the thoroughness of the Java specs, they should not be incompatible. If they were, you can expect any compatibility problem to be rapidly resolved. If I needed the special features of either of these products, I would use them with full confidence.
Another possible concern is the speed with which a vendor might update their own releases with certain bug fixes or security patches. For example, Oracle has stated that they reserve the right to immediately ship any ready patches to their own customers, while submitting those to the OpenJDK project for consideration. Certainly, any of the vendors providing commercial support are likely to rush a fix or patch to their paying customers. Those releases built as a courtesy to the community provided free-of-cost may take longer to update, likely after the OpenJDK project has incorporated a fix/patch.
And each vendor is free to modify their code base at will, as long as they comply with the Java specs. For example, the Corretto team at Amazon has already made improvements to their own release, and then shared those changes upstream to the OpenJDK project. There may a gap in time before OpenJDK incorporated those changes, if they decide to do so. So it is possible that various releases might differ. But at this point, all of the vendors in the Java community seem to have sincere commitments to work together to prevent fragmentation. So, again, I have no real concern here, but mention this for completeness.

Right now, there seem to be no free + easy Oracle-supported Java 11 JRE (only) options. Your options are:
Download and use an OpenJDK Java 11 JDK from the OpenJDK site.
Download and use an Oracle Java 11 JDK from the Oracle site ... and be sure that you fully understand the restrictions on "commercial use" that now apply to the Oracle Java 11+ releases.
Try to roll your own Windows JRE for Windows from the OpenJDK sources; see Create jre from OpenJDK Windows. (I wouldn't recommend doing this. There are better alternatives.)
Look into using the new jlink tool to create a custom image (basically a cut-down JRE) for your application. This seems to be the option that Oracle want 3rd-party application developers to use.
Talk to Oracle sales about a Java support contract, and specifically ask about how to get a JRE build. (I don't know what the answer will be. If someone does try this, and they get a positive response, please comment!)
Use a 3rd-party Java JRE distribution.
The list of Java vendors changes over time, but as of now it includes AdoptOpenJDK, Amazon, Azul, BellSoft, IBM, jClarity, Red Hat and SAP. See also: Difference between OpenJDK and Adoptium/AdoptOpenJDK
Some of these vendors offer JRE distros. Check their download sites.
Since (nearly) all Java vendors base their products on the same standard OpenJDK codebase that is used for Oracle Java, there is no reason to be concerned about the stability of a 3rd party JRE. Some vendors offer (paid for) support.
(Or switch from Windows to Linux. I can install an OpenJDK Java 11 JRE-only package from the distro package manager on recent versions of Ubuntu, Fedora, ...)
For those people who think that Oracle Java 11 and OpenJDK Java 11 are the same, please read the following from the Oracle download site:
Important changes in Oracle JDK 11 License
With JDK 11 Oracle has updated the license terms on which we offer the Oracle JDK. The new Oracle Technology Network License Agreement for Oracle Java SE is substantially different from the licenses under which previous versions of the JDK were offered. Please review the new terms carefully before downloading and using this product.
Oracle also offers this software under the GPL License on jdk.java.net/11
Notice that Oracle are saying that the licenses for Oracle Java and OpenJDK Java are different. (Not withstanding that the two are built from essentially the same source code base.) Ignore this at your peril!

You can use the "adoptopenjdk" project website to download latest jre and JDK https://github.com/AdoptOpenJDK/openjdk-jdk11
find latest link here > https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=hotspot
Edit:
Problem has been fixed
I have used their night builds to workaround the problem of missing JRE in JDK package
https://adoptopenjdk.net/nightly.html?variant=openjdk11

zulu still maintains the jre (11 - 16) and it is recommended by some vendors.
you can download it on their site: https://www.azul.com/downloads/zulu/

As java releases are coming faster do we need to migrate the old java code base to latest version?

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.

Difference between Java and Oracle Java for Redhat

I want to update my jdk for some security reasons in Redhat system and updated to jdk7u79 successfully.
Redhat has published some java vulnerabilities in their site with the name Oracle java for RHEL Server.
Do I need to update my jdk as mentioned in the RHEL site? Is jdk from oracle site is different from Oracle java for RHEL Server.
Reference

Oracle java is based on openjdk with some proprietary bits added:
– Sometimes those bits are supposed to increase performance (jrockit traces…),
– Sometimes those bits will improve compatibility (because they've been inherited from SUN and app authors tested against them since SUN era). A lot of the "stability" attributed to Oracle/Sun java is just app authors learning to avoid the bugs of Oracle/Sun proprietary bits, and adding workarounds that trip on jvms without those bugs (see also : IE6)
Red Hat java is based on the openjdk only
– pure openjdk is better integrated with the system. The openjdk guys try hard to remove residual java-isms and use the same conventions as other system apps
— pure openjdk is more forward facing. Oracle knows that SUN almost killed Java with byzantine combinations of proprietary tech it couldn't afford to maintain. Anything Oracle needs long term will end up in openjdk. It is sufficient for the openjdk implementation to achieve parity with the proprietary bits for Oracle to kill them – no $$$ in maintaining proprietary tech when similar free tech is available.
– it is very common for Red Hat to backport the code written for the next openjdk version in current redhat java, when it solves a problem in this version (as long as the current API is conserved), while Oracle will tend to wait for this next openjdk version before proposing it.
To my knowledge Oracle has been thoroughly disgusted by the way SUN handled java 1.6 (it was called java 1.6 but development was not linear, desktop/server/windows/linux jvms were all different with bits added in one version that could not be used in another due to coding shortcuts and complex licensing agreements, each of them lagged the others one way or another). Oracle intends to maintain a classic linear development pipe: openjdk next → current openjdk → oracle java
Whichever version you use you need to apply the security updates published by its maintainer. It's useless to use Oracle java as update to Red Hat java or vice versa, it's slightly different code with slightly different security bugs. Both companies have capable engineers and share security fixes in the openjdk trunk. When the fixed builds are published depend on embargo agreements and security fix policies. Oracle will tend to batch fixes in infrequent pre-planned releases, unless there is a critical vulnerability. Red Hat will publish as soon as there is something security-related to fix, be it big or small. Red Hat build processes are more agile than those Oracle uses. The Linux build processes are 100% automated, while Oracle needs to worry about windows & co.
Lastly Oracle Java as published in RHEL is a repackaging of Oracle files to use native Linux packaging tech and use the same path (etc) conventions as the openjdk packages (making it easy to replace one with another), while Oracle Java as published by Oracle still follows the very strange naming and path conventions SUN Solaris/windows people thought appropriate on Linux. It should have no more and no less security vulnerabilities than Oracle Java as published by Oracle (for the same version), just be a lot more convenient to deploy. It is designed to be just another linux package set, that can be deployed on many linux servers using native package deployment systems. When you have hundreds of servers to manage it is a great help not to have to special-case the jvm.
Each year in february Red Hat and Oracle top java people meet publicly at fosdem and present their current priorities.If you're interested you can consult their past presentations in fosdem public archives.