Is it possible to change from Oracle JDK to OpenJDK in production environment specially for JAVA EE applications?
Theoretically Yes. However in practice, There are many projects that work fine on Oracle JDK but not on OpenJDK and vice versa.
Since even a simple patch update of your JDK may lead to problems in your system, you have to thoroughly test the compatibility in a test environment first before moving in production.
Related
I am working on migrating my java application from Oracle JDK to adoptOpenJdk.So what changes would be required to migrate to AdoptOpenJdk.
Feature parity
Oracle has committed to keeping their Oracle JDK product at feature parity with the codebase in the OpenJDK project. So any Java app running on Oracle JDK should run on any other platform built faithfully from the OpenJDK codebase. You need not make any changes to your Java programming.
Be aware that OpenJDK only provides source code. For binaries and installers, you must look elsewhere. Several companies provide such binaries and installers. One of those is a joint venture known as AdoptOpenJDK. Others include Azul Systems, Red Hat/IBM, SAP, BellSoft, Amazon, Oracle, and Pivotal.
Most of the vendors, including Oracle, provide JVMs using the HotSpot optimizing compiler and runtime. AdoptOpenJDK (at least) offers you a choice to obtain a build using the OpenJ9 optimizing runtime instead. Your Java app should run well on either HotSpot or OpenJ9, but you may see a different performance profile.
See my Answer to a similar Question.
Be aware that the current licensing terms for the Oracle JDK product require that for use in production you must pay a fee. That product is free-of-cost only for non-production use such as development and testing. If you do not want to pay such a fee to Oracle, use their unsupported product at JDK.java.net, or use a JVM provided by one of the other vendors as shown in this flowchart.
I somehow understand the differences between Oracle JDK and Open JDK.
But I can't find reasons to use Open JDK.
Because Oracle JDK already has everything one would need and sometimes faster than Open JDK.
In which cases should someone use Open JDK?
Is it just for legality issues?
If yes, then what are issues?
That because I have been still develop all my projects using Oracle JDK
Other Answers are correct. Here is some other information as well, including vital changes as of early 2021.
Source-code versus Binaries/installers
understand the differences between Oracle JDK and Open JDK.
To sum it up: source-code versus binaries/installers.
OpenJDK is an open-source project, implementing the Java Specifications, JSRs, and JEPs that define the Java platform. This project publishes only source-code, not binaries or installers to get Java running on your computer (except for some early-access builds). Oracle is the principal participant in the OpenJDK project, alongside IBM & Red Hat, Apple, SAP, Azul Systems, Microsoft, and others.
Many companies provide distributions of OpenJDK for installation, as binaries or installers. Oracle is one such company.
Oracle actually provides two such products:
Oracle JDKA commercial product, with paid support plans. (Free-of-cost only for development & testing, not deployment. Read their terms.)
jdk.java.netA build of the OpenJDK source-code, freely available, unsupported.
Oracle has declared their intention to keep their commercial product Oracle JDK at feature-parity with OpenJDK. Oracle even went so far as to open-source and make available at no cost their formerly commercial tools Mission Control and Flight Recorder, both now a part of OpenJDK. So there is nearly no practical difference. One significant difference is that the Oracle company reserves the right to rapidly supply their paid support customer base with urgent patches not currently found in OpenJDK. Ditto for other vendors selling support.
[And for the record, Oracle offers a third implementation of Java, GraalVM, which is a very specialized product.]
Here is a flowchart graphic I made to help guide you in selecting a provider of a Java implementation.
And here is a list of motivations you might consider in choosing a distribution.
November 2017: At the time this question was asked, the reasons for choosing between OpenJDK and Oracle JDK include:
Availability of builds / installers for specific platforms. For example, last time I checked there were no Oracle JDK distros in ".deb" format for Debian / Ubuntu. And no OpenJDK builds for Windows.
Oracle JDK has some commercial features that can be enabled by people who have paid. They are not present on OpenJDK.
Oracle JDK has an annoying click-through license. This is a pain if you are trying to automate deployment; e.g. to cloud VMs. By contrast, OpenJDK on Linux (at least) can be installed and updated using the platform's package manager.
There may be issues if you wanted commercial support for OpenJDK.
There were no substantive license differences between Oracle JDK and OpenJDK if you just plan to use the software. (There are some constraints on binary redistribution for Oracle JDK, but they are about shipping non-standard or stripped-down versions of the Java platform.)
In the future, some of these differences will go away, according to this blog page:
Faster and Easier Use and Redistribution of Java SE
Update in December 2018:
As of January 2019, Oracle JDK Java 8 will be EOL for commercial uses. (But free support will continue until January 2020 for personal use.)
1
Java 9 and Java 10 are EOL.
Commercial uses of Oracle JDK Java 11 and later require a support contract or a subscription from Oracle. OpenJDK Java builds do not have this requirement.
Oracle do not provide support for OpenJDK Java builds, but support is available from 3rd parties. Third parties will also port Oracle security fixes to OpenJDK builds.
Further reading:
Java Is Still Free
OpenJDK Life Cycle and Support Policy (RedHat)
The future of Java and OpenJDK updates without Oracle support
What has changed in Java Release and Update Availability? (Azul Systems)
AdoptOpenJDK Support
1
EOL stands for end-of-life.
An end-of-life (EOL) product is a product that does not receive continuing support, either because existing marketing, support and other processes are terminated, or it is at the end of its useful life.
OpenJDK comes tightly integrated with the distribution update process. For example, on Fedora, this means that you simply can run
dnf update
without activating third-party repositories, and you will get the latest OpenJDK version with all relevant fixes.
OpenJDK is tested by the distribution vendor on this particular distribution. Oracle has different reference platforms for testing of OpenJDK. In the case of Fedora, software written in Java is tested with the OpenJDK version provided by the distribution, while the combination of that software with Oracle JDK receives much less testing.
Oracle also bundles their Java downloads with additional software such as browser toolbars, performance measurement and monitoring tools.
For those, who read this in 2019.
Java SE 8 is the last Java SE release targeting Desktop deployment (eg, Java Web Start and a stand-alone system JRE). Java SE 8 will be end of public updates in January 2019, after which commercial users need to either transition to other technologies, or purchase a Java SE Subscription.
So, another reason to use OpenJDK (in addition to what Stephen C said): it's free of charge for all purposes.
Cassandra 2.0.12 and Datastax Enterprise 4.6 both recommend using Oracle Java SE 7. However, public updates of Java SE 7 will cease in April 2015 meaning security updates and bug fixes will not be available without a support contract with Oracle.
My preferred option would be OpenJDK to avoid legal hassles with Oracle's click-through license (technically I can avoid the problem, but legally I cannot). However, it seems that OpenJDK is not recommended for 'reasons'. I can only see minor reasons why it doesn't work (using the string 'icedtea' in the version string) and no recent discussions, so I'm assuming it is not being tested and should be avoided.
Should I be doing new deployments with Oracle Java SE 8, OpenJDK 7, OpenJDK 8, or some other variant?
I would recommend using the version DataStax recommends if you can. While other JDK variants and versions will likely work, it would make sense to use what QA is actively testing with and others in the community are using. Cassandra even goes so far to warn you if you are using OpenJDK or a non-Oracle JVM (code).
You should be able to get away with using OpenJDK 7, but just beware that you may encounter various problems with heap, load, kernel errors, etc. With regards to Java8, Cassandra 2.0 won't compile on Java 8 (CASSANDRA-7028), but you should be able to run with it.
I'm writing Java code that will run on an AIX server. I'd like to know the difference between IBM's JDK and Oracle's JDK, and if the JDKs have the same classes. Does the IBM JDK have all the classes present in the Oracle JDK?
Are there any IBM documents that describe the differences between the two JDKs?
The biggest difference between the Oracle and IBM java runtimes is that they have independent Java Virtual Machine (JVM) and Just In Time (JIT) compiler implementations. IBM needed to build their own JVM and JIT that could run java programs on platforms such as z/OS (mainframes), AIX and Linux on Power processors, where other Java implementations would not run. The JVM and JIT are part of the Java runtime internals and they should not change how you write your Java programs. There are no documents listing the big differences between Oracle JDK and IBM, because the goal is to make them compatible. As others have said already, they are both implementing the same standard spec and Java API. That said, there is a lot of Java documentation from IBM, available at:
http://www.ibm.com/developerworks/java/jdk/docs.html
One area that could affect you as a programmer is that the IBM JRE has its own implementations of Security providers, which might need to be configured differently. These are documented in a Security Guide - the Java 8 version is here:
http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/introduction.html
I work in an environment where we use Java 1.6, deploying to Oracle (JRockit), IBM and Oracle/Sun JDKs.
The three are remarkably comapatible. Apart from the occasional difference (e.g. in JAXWS startup behaviour) we strike remarkably few problems.
There are no huge holes where one JDK is missing stuff that is in others.
I meet a big difference in the GBK encoding. The ibm jvm GBK is stand for the ibm936, but the openjdk or oracle jdk is the CP936. CP936 is the real GBK standard, as knowned the windows-936. So if you meed the strange GBK problems, you can see the IBM solutions
If I'm deploying to servers with WebSphere 6.1 (Java 1.5), should I use IBM's JDK on my build box? Or will Sun's JDK compile to the same binary?
If I should use IBM's, where can I get the Windows x64 version?
I would as much as possible try to keep development as close to production as possible. Ibm and Sun's JDK's certainly both satisfy the SDK certification, but they are by no means identical. Their instrumentation and memory management are at least slightly different. If nothing else, the bugs in the JDK will be different, which your code may only trip over in one scenario vs. another. It'll also probably only happen at 4 am, and when the moon is full especially when you have company over.
I can't tell you where to get IBM's jdk, but if you've got a license to websphere at your company, you should have a contact at IBM to get you a link to that JDK.
Good luck, and always try to minimize differences where possible.
It should not make any difference. It will probably not be exactly the same binary but 100% compatible. I assume you're using external libraries anyways like log4j or maybe hibernate or whatever and those are not built using the IBM JDK.
There are differences in the JREs, however. For example, I remember that when I listed methods or fields of a class using reflection, the IBM JRE used to give them to me in a different order than the Sun one.
I would use the same JDK to build that is going to be used when the application is deployed (if you have control over that).
The binaries may be different if the compiler is different, but they should be semantically identical. I don't know if IBM wrote its own compiler. The JRockit JDK actually uses the Sun compiler but the JVMs are different. So with JRockit the binaries are identical.
If the application is used with different JDKs at run time, I would still build with the one that you think will be used at deployment time most of the time and do some runtime testing with different JDKs.
The IBM JDK ships with J9 VM and SUN JDK runs on Hotspot VM which have different algorithms to function. You application may not perform the same if you deploy and tune in SUN JDK and your production uses IBM JDK for WAS. Check with the vendors and open a ticket,let us know how it goes.
Compiling with any JDK should not cause a problem unless you are referencing classes outside of the java.* and javax.* pacakges (which you should not be.) Of course there's always a chance that there's a discrepancy between a given vendor's JDK and the spec which could cause some really weird runtime errors that are hard to track down, but I've never seen this before in my experience.
I would recommend running any test suites you have using the target JRE as runtime behaviors differ between vendors much more often than compilation semantics do.
JDKs are compiling your code to a bytecode and not directly to machine code. Is expected that compilers of different vendors generating cross-vendor compatible code. For example IBMs compiler for JDK1.5 will produce code that runs on SUN's JDK 1.5 and later without any problem.
Another issue is how compilers optimizing the bytecode, I have not information that some compilers performing better optimization than others. The largest part of optimization is performed during runtime by JVM (for example JIT (just-in-time) or AOT (ahead-of-time) strategies).
Having worked with WebSphere a long time the version of the JDK is very important. WebSphere 6.1 ships with an IBM JDK 1.5 (or is it 5). When you patch the WebSphere there are equivalent patches for the JDK as well. While it may work with a different version of the JDK (even a different vendor) I doubt you will get much support from IBM if something goes wrong.
If you need a 64 bit JVM I would suggest that there is probably a 64 bit build, while I cannot comment on windows specifically I can tell you there is a 64 bit WebSphere 6.1 build for both AIX and Linux.
The best answer is to check with the vendor and see if they will support your configuration. What you don't want to do is get it working, then have an issue in live, call up support and find out that you have an unsupported environment.
They should compile to the same bytecode specification, although they may compile different bytecode (much as in the same way different C compilers generate different machine code). I don't think there would be any problems in running the resulting code - I've compiled Java 1.4 on a Mac and then deployed to IBM's J9 running on a PocketPC before with no problems (this was before J9 could handle Java 5 bytecode).
Regardless, I'd definitely make your compilation platform a bullet point on your readme file so that your client can see if it is a problem.
Alternatively, you could build and deploy with ANT, and use Sun's JDK with ANT.