We Keep Coding

Migrating to OpenJDK from Oracle JDK

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.

What is the reason to use OpenJDK?

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.

Why are there differences between openJDK and oracleJDK

I have problems with the following method:
sun.security.x509.AuthorityKeyIdentifierExtension.getEncodedKeyIdentifier()
It exists in openJDK but it does not exist in oracleJDK. I always thought that except for some special cases regarding licensing those JDKs should be the same ...
While I can work around that issue, I fear there are other incompatibilities I might not be aware of.

Classes that are not part of the standard packages and classes that are deprecated can be not part of a jdk.
In your case you can try to solve the problem using the classes of the package javax.security.cert. Searching for it on google you can find some tutorials like this one.
Just to complete the answer is true that "generally" both compiled code comes from the same source code in the open jdk and in the oracle jdk. But oracle jdk and open jdk have different licences so there are also few little differences. Generally the differences are not related to the source of common classes, but to the presence or absence of classes or entire packages. As an example see the font library.
This is not the only difference. As you noted in your code also the security packages are different, because the open jdk added also the old sun version of x509 certificate classes and the oracle jdk not. There is no guarantee on what classes are included or not if they are not part of the standard packages. So if you have problems running your code on different jdk environments use only standard packages or explicitly import libraries as you need.

That class is not part of the public Java API and is therefore not guaranteed (or even likely) to exist in every JRE implementation, nor every release of the same provider's implementation.
If it's not part of the standard APIs, then you can't count on it.
Java Standard Edition 8 - all JDKs should provide these
Java Enterprise Edition 7 - some environments and libraries will provide these
While the OpenJDK and OracleJDK implementations happen to be very similar as they share a common history, they could diverge (or converge) in any private APIs or implementation details at any time, simply because they are separately-run projects.
Instead you should be using the appropriate implementation-agnostic APIs in java.security and javax.security for dealing with certificates.

Oracle JDK was previously called SUN JDK and that was before the takeover by Oracle. Earlier, it was the official proprietary implementation of the Java language. After the takeover it was named as Oracle JDK and Oracle’s team maintains the JDK.
OpenJDK is an open source implementation of the Java Standard Edition platform with contribution from Oracle and open Java community.
Actually, Oracle JDK’s build process builds from OpenJDK source code. So there is no major technical difference between Oracle JDK and OpenJDK.
Apart from the base code, Oracle JDK includes, Oracle’s implementation of Java Plugin and Java WebStart. Also includes third party closed source and open source components like graphics rasterizer and Rhino respectively.
How Oracle JDK and OpenJDK is kept in Sync:
All of the development and bug fixes happens in OpenJDK and then they are propagated to the Oracle JDK. Security fixes happens in private forest without public code reviews unlike general fixes, then they are pushed to Oracle JDK and then to OpenJDK.
more on http://javapapers.com/java/oracle-jdk-vs-openjdk-and-java-jdk-development-process/

What does Oracle JDK 7 and JRE 7 Certified System Configurations really mean?

Oracle Java 7 has a list of certified platform http://www.oracle.com/technetwork/java/javase/config-417990.html#os popular server Operating systems such as debian and ubuntu are not certified.
I have downloaded the jdk-7u3-linux-x64.tar.gz and it seems to run on Ubuntu should I be concerned about running Oracle Java 7 on a non certified Oracle platform for production? Is this certified platforms list just a marketing thing or is some technical reason why Oracle Java 7 would run differently on Redhat vs. Ubuntu?

While you may not see a difference between, say, Ubuntu and RHEL when running a JVM, you would probably receive far different reactions if you encounter an issue and request support from Oracle:
Using a certified OS increases the possibility of a quick fix. Not only is it easier for the support staff since they have to be familiar with and test on far fewer platforms, but they are also bound to produce a quicker fix due to marketing reasons and possibly due to various contractual obligations.
On the other hand, you are far more likely to receive a "sorry, can't reproduce it on our system" reply if you are using an unsupported distribution.
I would not expect the JRE to run differently on an unsupported system - at least not for long. Any fixes usually find their way to the more generic packages pretty quickly.
That said, I have encountered other applications (e.g. IBM PurifyPlus) that were so tied to specific versions of the supported platforms that they were not usable even on updated versions of a supported platform (e.g. SLES 10 vs 10SP1). And by tied I mean major functionality issues, not a silly version check. Apparently in some cases there are technical reasons, arguably due to a badly designed application, for using a supported platform.

If I understand correctly on certified OS jvm runs as expected, others not guaranteed. Every OS has its own instruction set (and interpretation of instruction set), Each OS JVM is coded for that specific insturction set. JVM for certified OS are tested against those instruction sets.

Does it matter which vendor's JDK you build with?

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.