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.
Related
Is JRE contained in JDK installation or I'm wrong? Why do I have to install specifically the JRE in order to play games based on Java, for example Minecraft?
If JVM<JRE<JDK
This isn't true, but JRE < JDK is more or less true.
a specific JRE installation is also required to make games work?
Actually, JREs are dead; java8 is now over 5 years old and is the last version where a JRE is the intended distribution model. The JRE model works as follows:
The developer installs a JDK and builds their java application with it.
The developer ships a bunch of jar files to the end user.
The end user will download a JRE from e.g. oracle and installs it. That user and oracle work together to do the maintenance on this (keep it updated for example to close a security leak in the JRE); developer is no party in this at all.
The reason the JRE exists at all is because it can be simpler and smaller, and its download and maintenance can be streamlined for end users and not developers.
This is also why a game would want a JRE: A JDK doesn't, as a rule, ship with managed security updates because a JDK is targeted at developers who are assumed to know better and keep it up to date. (They don't, of course, but that's another issue).
This model is obsolete. The new model is:
The developer installs a JDK and builds their java application with it.
They use jlink or other installer creation tools to produce an installer which is then shipped to the end user. jlink can make a custom cut-down version of the JDK without developer tools and with only those parts of the java libraries that are needed. Even smaller than a JRE, in other words.
End user installs. They have no arrangement with oracle or any other 'JRE provider' and do not need a JRE on their system; even if one is there, it won't be used. Distribution of any updates (including security updates) to the cut-down java runtime being used are entirely the responsibility of the app maker.
That latter model is in practice how most 'runs on the desktop' java software was distributed anyway: asking users to install a JRE is an annoyance, and is also unreliable: What if your app doesn't run on jre8 because you wrote it for jre6 and something updated in 8 breaks your app, but the end user updates their jre?
Now that latter model is the official model, which makes your question mostly moot.
Minecraft presumably needs to update its deployment.
NB: Some companies, such as Azul, still distribute something they call 'jre11'. These distributions are meant for shops that cannot easily transition away from the old distribution model of 'user maintains a JRE, developer distributes just jar files', but do want to use new java features. Oracle doesn't distribute these, and this distribution model is no less obsoleted. 'obsolete' doesn't mean 'impossible', just 'not recommended / you need to find some time to move away from it / definitely do not do this for new projects'.
Is JRE contained in JDK installation?
Pre Java 11 it was but post Java 11 it isn't
Why do I have to install specifically the JRE in order to play games
based on Java, for example Minecraft?
Looks like from Java 11 on things have changed: https://stackoverflow.com/a/53733414/1098361
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 am not able to understand that after module system is introduced in our java language. Is java9 and above still platform independent or not ? I am asking this question because I have read that now every application will have its own jre inside it. So, how will this single jre run on all OS, like windows, Linux, or Mac OS.
You are conflating two different changes recently made to the Java platform:
Retiring of Java Web Start & Applet technologies
Modularization
Retiring desktop-technologies
Recently Oracle announced the phasing out of the Java Web Start technologies, in addition to the already-deprecated Applet technology. See item JDK-8184998 in Java 9 Release Notes:
Java Deployment Technologies are deprecated and will be removed in a future release
Java Applet and WebStart functionality, including the Applet API, The Java plug-in, the Java Applet Viewer, JNLP and Java Web Start including the javaws tool are all deprecated in JDK 9 and will be removed in a future release.
End-users will no longer be encouraged to install a JDK or JRE on their computer.
For more details, see the eight-page 2018-03 white paper from Oracle, Java Client Roadmap Update.
So then, how are developers of Swing or JavaFX apps to deliver their software to the end-user?
Oracle suggests packaging up your app along with a JVM & JRE for delivery as a single launch-ready applications on that appears on the client to be just another app alongside the native apps. Such “double-clickable” app-packaging has been commonly done on the Mac since the beginning of Java. But what was once an obscure art on other host environments (Linux, BSD, Windows, etc.) will now be the norm, as it is on macOS.
In yesteryear, bundling a Java runtime with your app required jumping over some licensing hurdles. The legalities have eased with arrival of the open-source OpenJDK project, and possibly with other implementations†.
You will need to prepare different releases of your app for each hosting environment. While your Java code runs independently of the host OS, the JVM is built of native code to interact with one specific kind of host. So you will need to build a Linux release with a Linux JVM, a macOS release with a macOS JVM, and so on. While that may seem like a downer, the upside is that you no longer need to worry about users having the wrong JVM version installed, or no JVM at all. Now the JVM’s presence and version are under your control. Your end-users and customers will no longer need to be aware that your app is Java-based.
Modularization
That need for app-packaging has nothing to do with the modularization of Java. As I said, it has been done for decades on the Mac.
What modularization brings to the party is that the JVM/JRE you bundle into your delivered app can be customized to contain only the Java Modules actually utilized by your particular app. This results in a smaller size, so your finished app is smaller, downloads are faster, less storage is used, and your app may load faster.
The open-source jlink “Java Linker” tool helps with the packaging work, so you can assemble and optimize a set of modules and their dependencies (only the ones actually called by your app) into a custom run-time image. This modular run-time image format is defined in JEP 220.
† On a related note, you may want to read the white paper Java Is Still Free to understand how and where to obtain a Java implementation for your app, and what support may or may not be offered in either free-of-cost or paid releases.
By the way, you may find helpful this Answer on a related Question, with a flowchart of choosing various sources of a Java implementation.
Is java9 and above still platform independent or not ?
Yes. It's as platform independent as it ever was. The module system has nothing to do with platform independence.
now every application will have its own jre inside it.
It doesn't have to, but it's more and more recommended as time goes on since fewer people have Java installed separately on their systems. This used to be a given, but that number has been declining for the last decade or so, and now (outside of Java developers) pretty much no-one has a standalone JRE installed.
how will this single jre run on all OS
It won't. You will bundle a separate JRE for each platform you want to distribute for. But JRE's for all platforms are still freely available, and the same Java code will still run on a JRE for any platform.
The module system doesn't influence the OS independency of java in general. Java applications that make use of the module system need to be run in a JRE. This can be either an OS specific pre-installed JRE as usual or a tailored runtime image (application embedded JRE) created with JLink.
The module systems main purpose is to provide you a managed way to split your application into different logical modules. E.g. into different .jar files that can be loaded at runtime - no matter on which operating system.
In summary, you have the following options:
Make sure that your client has the right JRE pre-installed. This could be dangerous, because (normally) you are not in control of his updating behavior.
Ship your application together with an official JRE.
Tailor your own, application and OS specific runtime image using JLink. Ship it bundled with your application.
But, suppose I do not know what OS my client would be running so how
the server will decide what image he should give to him. i.e., a Mac
Image, a Linux Image or a Windows exe.
You have to know the target OS and deliver the right runtime image.
While Java 9 makes it easier to ship a JRE which is more compact and specific to the needs of an individual application, you are not required to do so. If you were already planning to ship a JRE with your application it can be smaller with Java 9 than earlier versions.
It doesn't mean you have to ship a JRE, an application which wasn't shipped with a JRE is unlikely to start shipping with one now, and in fact Java 11 only ships as a JDK.
From this link on Java 9 features;
JLink allows you to create custom runtime images that only consist of your application modules and those JRE modules that your application requires. The result is likely a smaller runtime image, which uses fewer resources than a default JRE.
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.
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/