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/
Related
Is JVM open source code? If not, how can I get the code of JVM?
It depends entirely on which JVM you use.
If you use the OpenJDK JVM, then you can get the source code from here (or here from a list of OpenJDK projects).
If you use the Kaffe JVM, you can get the source from here.
If you use the Sun JVM version 6 or later, then you can get the source from here.
If you use a Sun JVM earlier than 6, then you can often get the source under an academic license. If you use an IBM, Oracle, HP, or other JVM, then the source is not open.
Update May 2013
The Version 6 source can still be accessed by the above link, or it can be accessed via this link. This latter link also includes a handy genealogy table that shows how the Oracle JDK and OpenJDK versions match with each other.
Additionally, a more up to date version of the Java 7 source can be found here. This also includes the fixes for the releases of Java 7 since GA.
And, of no surprise to anyone, the Java 8 sources can be found here.
Have a look at hotspot JVM here: http://openjdk.java.net/groups/hotspot/
The core part of the JVM is in the hotspot module of the OpenJDK. However what you need is more likely to be in src.zip.
The hotspot module apart of those classes is
mostly in C++
not always easy to understand. This has improved over the years and new code tends to be better as they are more aware that the code will have broader consumption.
often not what you are looking for.
For this reason if you want to know how the JVM runs it is best to look at the commonly used classes. For example, even something as low level as how lambdas really work at runtime is mostly in the src.zip not much is in the JVM.
Most of the source for the libraries come with the JDK in the src.zip file. Your IDE will use that automatically. You are much better off being familiar with the classes in these libraries than playing with the JDK itself.
There is no open source jvm even if there were you can't bypass Oracle's stupid classpath exception. In short openjdk is still tied to $$ driven scheme that forces you to contend with a comercial vm. No different from Microsoft really, you can work with C# under what ever os they even provide .net libraries free but maintain control over Visual Studio which practically forces the end user to make use of Windows as the chosen environment.
I have a web application that uses embedded Tomcat, which I'll distribute as a desktop app. Since I don't want users to deal with the installation of JRE, I decided to bundle JRE in my installation package, however, I was wondering if there's a reduced version of JRE in order of having a smaller installation file size. For example, I removed all the CORBA related files from JRE and everything seems to be working fine, so I guess some other files could be removed without affecting Tomcat's functionality, but I really don't know which other files should I remove.
If anyone has done this before, I'd appreciate your comments.
AFAIK, there aren't any official cut-down Oracle JRE releases. Certainly not free ones, though I imagine Oracle would create one for a customer who was willing to pay (enough).
If you created and distributed a cut-down JRE based on the Oracle JRE, it would be a violation of the Java Binary license ... which expressly forbids such things. You would need to get permission from Oracle to do this. The same applies to other suppliers, so the chances of you finding a free cut-down JRE based on OpenJDK are "vanishingly small".
I'm don't know for sure the legal constraints on building a cut-down JRE starting from the OpenJDK open-source codebase. I suspect that it is legal from the copyright perspective, but that you need to understand of patent and trademark issues. (For example, a cut-down JRE would not pass Java Standard Edition TCK testing, so you would not be permitted to use trademarked terms like Java and JRE to describe it.)
You should to talk to a lawyer if you intended to build and distribute cut-down JREs to anyone else.
I understand that Azul distributes cut-down JREs as a commercial (non-free) offering. Google found this for me:
The short answer for why we do not remove contents of Zulu JDK is for compliance with Java Standard Edition TCK testing. Changing the contents of tested build after the fact is often believed to be an invalidation of TCK coverage, and we cannot ship without that copyright/patent/trademark umbrella. Secondly, Azul offers cut down JREs and Compact Profile binary builds as a commercial (non-free) offering. We still need some way to monetize Zulu (else the business is not self sustaining) so charging fees and offering only private access to the set of lean & mean production runtimes is core to our business model.
The compiler display warnings if you use Sun's proprietary Java classes. I'm of the opinion that it's generally a bad idea to use these classes. I read this somewhere. However, aside from the warnings are there any fundamental reasons why you should not use them?
Because they are internal APIs: they are subject to change in a undocumented or unsupported way and they are bound to a specific JRE/JDK (Sun in your case), limiting portability of your programs.
Try to avoid uses of such APIs, always prefer a public documented and specified class.
The JDK 6 Documentation includes a link titled Note About sun.* Packages. This is a document from the Java 1.2 docs, so references to sun.* should be treated as if they said com.sun.*
The most important points from it are:
The classes that Sun includes with the
Java 2 SDK, Standard Edition, fall
into package groups java.*, javax.*,
org.* and sun.*. All but the sun.*
packages are a standard part of the
Java platform and will be supported
into the future. In general, packages
such as sun.*, that are outside of the
Java platform, can be different across
OS platforms (Solaris, Windows, Linux,
Macintosh, etc.) and can change at any
time without notice with SDK versions
(1.2, 1.2.1, 1.2.3, etc). Programs
that contain direct calls to the sun.*
packages are not 100% Pure Java.
and
Each company that implements the Java
platform will do so in their own
private way. The classes in sun.* are
present in the SDK to support the Sun
implementation of the Java platform:
the sun.* classes are what make the
Java platform classes work "under the
covers" for the Sun Java 2 SDK. These
classes will not in general be present
on another vendor's Java platform. If
your Java program asks for a class
"sun.package.Foo" by name, it may fail
with ClassNotFoundError, and you will
have lost a major advantage of
developing in Java.
Try running your code with a non-Sun JVM and see what happens...
(Your code will fail with a ClassNotFound exception)
Yes, because nobody guarantees that these classes or API will be the same with the next Java release and I bet it's not guaranteed that those classes are available in Java versions from other vendors.
So you couple your code to special Java version and loose at least portability.
Sun's proprietary Java classes are part of their Java implementation not part of the Java API their use is undocumented and unsupported. Since they are internal they can be changed at any time for any reason that the team working the Sun JVM decides.
Also Sun's Java implementation is not the only one out there! Your code would not be able portable to JVMs from other vendors like Oracle/BEA and IBM.
Here is Oracle's answer: Why Developers Should Not Write Programs That Call 'sun' Packages
I recently had a case that showed a real-world problem you can hit when you use these classes: we had code that would not compile because a method it was using on a sun.* class simply did not exist in OpenJDK on Ubuntu. So I guess when using these classes you can no longer say things like 'this works with Java 5', because it will only work on a certain Java implementation.
I am a bit confused. In Oracle jre 1.7, we have the package com.sun.webpane.webkit and in oracle JRE 1.8, we have com.sun.webkit (no webpane)
How are we supposed to handle such change so that an application works on both environment, any best practises ?
Thanks
You should not use com.sun classes in your code. Such classes are not part of the public API which is supported by Oracle or the OpenJDK for the JDK and JavaFX. Oracle makes no guarantees that com.sun classes will be backwards compatible between releases.
Oracle do guarantee that the public APIs, e.g., java.* and javafx.* will be backwards compatible between releases. So stick to using only supported public APIs in your code and your code should work much better across different Java releases.
For the particular control you are trying to utilize (the webkit implementation embedded in JavaFX), the public API for that is the javafx.scene.web.WebView API.
Our Java Applet is built using JDK 7u7.
We have a client who is worried that this exposes them to security flaws that were patched between 7u7 and the current Java 7 release (7u72). (They're not worried about any specific known issues, just "concerned".)
I believe the answer is that because the package is dependent on calls to the JRE libraries, it will call the (fixed) 7u72 libraries, and therefore the fact that it was developed against 7u7 will not be an issue.
Is this correct? A link to authoritative statements on this point would be much appreciated.
It is correct. Output of compilation is defined in the java VM specification in class file format, which has not changed between java update releases, it doesn't matter if it's compiled in 7u7 or 7u72.*
You can see all the java virtual machine specifications since java 5 on this page. There are no other changes to the specification, so it has only changed between major releases.
*on further thought, this assumption is true only if there hasn't ever been security-related bytecode generation bugs in JDKs. I've never heard of one, and certainly between versions 7u7 and 7u72 there isn't any. I guess it is possible in theory, but at least for the cases you specified there aren't such security issues.