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/
Oracle is planning to make its JRE paid from Jan 2019 onwards. We need to find another vendor that supplies the Java Web plugin for free. Do any of the OpenJDK vendors provide this plugin?
Oracle hosts the plugin on this link - https://www.java.com/en/download/
Certainly the OpenJDK has the java.applet.Applet and javax.swing.JApplet classes. That is all that is needed, technically, to enable applets. Of course, using them in a browser, at least for general consumption, is no longer an option.
But why use Java? Recent developments allow most traditional Java applets and Java applications (both) to be run in JavaScript. The process is still in beta, but it has been highly successful. Development is all in Java; deployment is in Java and JavaScript simultaneously. Minimal recoding is necessary, mainly to reconfigure threads to be "state-like" and not require wait() and notify(). And the same for dialogs. But our experience is that both of these issues are easily worked around. It's not perfect. Certainly there are limitations -- a few missing Swing classes, "not so long" long numbers. Speed 15-30% Java. Some pretty major applications have been converted. (Jmol was the first.)
For more information, see https://github.com/BobHanson/java2script for details.
Why do we have two versions of Java ?
The jdk from Oracle and the one from OpenJDK.
And why is it that
OpenJDK is available only for Linux ?
And on Wikipedia,I find that
Java is open source .But ,I find a copyright information inside the
Oracles JDK saying everything restricted ???
Open JDK is trying to reinvent the wheel by giving you freedom of choice (you can use cool OpenJDK JVM or the mainstream Oracle one)
If something is that cool OBVIOUSLY it's only for linux
that question is out of SO scope, besides I'm not sure myself...
There are many java distributions. Oracle JDK is just the reference one, but others like Open JDK exist. IBM has its own, for example. While they all share the mandatory set of features, each one goes beyond that and implement their own proprietary set. Parts of Oracle JDK are not open source and it requires licensing for embedded devices, and this is why Open JDK exists - to provide a fully free Java implementation. Now, Java, as in "the spec" is open source and most of Oracle JDK is as well. Other companies are allowed to make their own implementations as long they pass Oracle's test that certify compatibility. Still, Oracle owns the Java trademark and I think the ability to certify other implementations. Somewhere there lies in the dispute with Google and their Java implementation (same with now defunct Apache Harmony).
As for the Open JDK on Windows, it can be done by building the sources (like this guy here did). The binaries do not exists probably because there was no demand. It's only Linux that imposes limitations on proprietary software.
How can i bundle a stripped down JVM to run just my application?
i would like to strip down the JVM so that i can include it in my application. I know that exe wrappers can do this but what i would like to know is how? so that i can script it and create bundles for multiple OS's not just Windows.
Even though it might be possible to strip down the JRE distribution from a technical perspective, please have a close look at the license agreement. For Java 6 it states:
[...] Sun grants you a
non-exclusive, non-transferable, limited license without
fees to reproduce and distribute the Software, provided
that (i) you distribute the Software complete and
unmodified and only bundled as part of, and for the sole
purpose of running, your Programs [...] {Supplemental License Terms, (B)}
I'd read it like that: you're only allowed to distribute a complete (Sun) JRE 6 (or JDK 6).
You may considerably reduce the download size of java applications while maintaining compliance with the license.
For the vast majority of users (that is to say those who have a Java runtime installed) you shouldn't need to distribute your own custom execution environment, and in fact doing so goes against the "spirit" of Java.
Java code is designed to be runnable in any environment, and you can easily replicate the double-click-and-run behavior of an .exe with a Java program by creating an executable .jar.
This may not be quite the answer you're looking for, and if so the answers discussing licensing stripped-down JVMs are what you need. But most Java developers should have no need to jump through such hoops. Simply distribute your Jars and let users install a Java runtime themselves.
Which (commercial or free) installer tool would you recommend to replace InstallAnywhere as the installer for a Java EE application? What do you specifically like about it, and what are its downsides?
Some requirements:
Must support running custom Java code as part of installation procedure
Must support Windows, including latest 64-bit versions like Windows Server 2008; support for other target operating systems is a plus
Must be able to install a bundled application server (such as Resin or Tomcat) as a service on Windows
Must support basic stuff like copying and moving files around, editing configuration files, extracting ZIPs, etc.
(Must support bundling a specific version of JRE; at the very least by including a ZIP to be extracted)
Edit: a few more points:
Preferably does not depend on a preinstalled JRE (or any other 3rd party runtime environment or library) on target machine; in other words, can produce an independent Windows .exe (or .msi)
The tool should preferably be cross-platform so that installer development can be done on Linux, Windows, or Mac.
Should preferably have a decent GUI for putting the installer together. Once that is done, however, it must be possible to skip the GUI and make installer building part of automated build process.
In this case, unfortunately, SO didn't tell us much that we didn't know already (and indeed the tool we ultimately chose was not mentioned in any answer). However, I'm posting our experiences here, as they might be helpful to others later on.
We (quickly) evaluated the following installer tools, mostly by looking at their websites and browsing for other information on the web: Actual Installer, Advanced Installer, BitRock InstallBuilder, Inno Setup, Install Creator, Installer VISE for Windows, InstallShield, install4j, IzPack, NSIS, openInstaller, Scriptlogic MSI Studio, Smart Install Maker, Symantec Wise Installation Studio, and WiX.
We screened out most of them early on, and ended up shortlisting two options for closer evaluation: BitRock InstallBuilder and install4j. For these tools, we downloaded evaluation versions and did some prototyping, to see if the things that are most important to us are really supported, and how easy or hard it is to get things working.
Both of the options were good in many things (and both seemed good alternatives to InstallAnywhere):
They produce completely native and pretty Windows .exe installers that are
easy to customise with your own graphics etc.
Both tools could easily be automated so that installer building is triggered from Ant. (With install4j it literally took me just five minutes to learn it and then implement it.)
Both companies seem to have good support (well, at least for prospects evaluating their products ;-) Especially from BitRock we got very quick replies.
In the following things install4j seemed better than BitRock for our needs (many of these are subjective, of course, so YMMV):
install4j definitely has better support for running custom Java code - it can be done at any point during the installation, and regardless of whether there's any preinstalled JRE on the system.
BitRock uses a more hard-coded sequence of installation steps while install4j is more flexible. In install4j, adding custom screens and forms (with or without custom Java code), asking user for input, etc., can be done at any point, before or after installing any files.
Also some basic things like defining the filesets that are to be copied to the target system, and adding an installation step to replace certain strings in configuration files seemed somewhat easier in install4j.
install4j has better support for JRE bundling
When creating installers on Linux, the look & feel of install4j IDE was nicer (more "native") than that of BitRock
(install4j's licensing options were better for us - we strongly preferred a couple of floating licenses to named licenses for all developers or an expensive "site license")
So ultimately we went with install4j. Here are some more details on why it was impressive:
Its IDE, where you put the installer together, is very simple and easy to use - I could figure out how to do most things I wanted quickly, even without looking at documentation. And when I did have to check something in the documentation (e.g. how to refer to installer variables; how to get started writing custom Java code against the install4j API), it didn't take long to find what I needed.
You can completely customise the screens and actions during the installation procedure, and also add custom screens and actions (coded against their Java API) at any point. This was important to us because we need to reuse existing custom Java code from the old InstallAnywhere installer.
In some small details, install4j seems ideal for Java developers. For example, if you want to add a validation script to check some user input, you can code that very quickly in the install4j IDE itself, using plain old Java, with coding assistance resembling that of IntelliJ IDEA.
We deemed the cost of install4j floating licenses reasonable, considering how good the tool is (and downright bargain compared to the inflated pricing of InstallAnywhere...)
In short, it seemed like the best installer tool available for deploying Java applications.
We created BitRock InstallBuilder, a crossplatform installation tool after some frustrating experiences with InstallAnywhere and specially its cousin (now defunct) InstallShield MP. More than half of our clients use our tool to package Java-based software but the tool is native, not Java-based. That means we have a number of advantages such as native look and feel (incl. Vista, GTK, Qt, etc.) and no need to do self-extraction previous to installation (faster startup, less space requirements) to mention a couple. To answer your specific questions:
Supports calling Java code as part of the installation at multiple points in time (such as when a certain page is displayed, files being copied, at uninstall time, etc.). The code is not compiled in the installer, but it can be called externally and the result used in the installer. If you are more specific about which kind of code that you need I can provide specific sample code. We have a lot of built-in actions for functionality that needs to be manually added to other installers, so you may not need to write that code in the first place!
We support all versions of Windows, including 64bit and Windows 2008 (multiple customers have certified on those platforms using our installers)
We support bundled applications servers, including Tomcat, Resin, JBoss and others. Take a look at BitNami for examples of such stacks that we have created.
We support copying and moving files, substituting values in config files, unpacking files and most other common installation functionality. One of our principles is that the installer should provide built-in support for common installation actions and have an easy, clean interface for invoking external code that is specific to a client's product.
We support bundling JREs, as you mention is often enough just to bundle the JRE directory and setting the appropriate value for JAVA_HOME in the launching scripts
You can take a look at some of our customers such as MySQL, Samsung, Motorola, GitHub, etc. InstallBuilder is a commercial product, but we offer free licenses for open source projects and discounts for small business and microISVs.
Just want to add that my company has used InstallAnywhere for about 6 years but we have decided to move on. The reason is two fold.
First of all their pricing is absolute highway robbery and the licensing is severely restrictive compared to direct competitors like INstall4J and BitRock.
My other problem with InstallAnywhere is the product is only minimally maintained. I have been using the product for 6-7 years through many different versions and bugs are rarely fixed and you surely can't expect new features. Essentially all you can expect is that they will add support for the new version of windows/mac as it comes out. Their support charges are quite pricey, but I have never had a support request actually implemented. When I first bought the product I believe it was from a company called ZeroG who were focused solely on this product. They actually maintained and improved the product. Back then it was the only real ticket and they were leaps and bounds above the competition.
Then it was acquired by Macrovision and then Flexera. Ever since ZeroG sold the product it has been an ancillary product for the owning company and the focus on it has been poor. It seems like it was bought more to complete a suite of products rather than because the company actually wanted to maintain the product.
Word of caution, evaluate these products carefully because you can become tied to them. We would have left the product sooner, but we put so much effort into not just the installer, but setting up an automatic update scheme based on the features/limitation of the product that it is expensive to leave the product because of the labor investment to reproduce this in a new product.
Just my take, but I wouldn't recommend InstallAnywhere.
I can vouch for izPack. It's Ant-based so you can package up an Ant install in it, and that Ant install can contain custom tasks, and/or scripts written within your Ant build.xml (e.g. using Groovy, Beanshell or any BSF-enabled scripting language). So it'll cover your customisable requirement.
I've used it in the past for all the above - unzipping/services/custom code. It's multi-platform, although I can't vouch for that specific instance above (64bit Windows). But if it runs Java, you should be fine.
The one headache is the JRE. You'd obviously require some JRE to run this. However I think you should be able to pack up and execute a specific JRE installation within izPack.
Currently we are using GetDown to handle distribution of our swing applications. We use Tomcat to distribute updates and GetDown to download those updates. It's really flexible and powerful, and much better than java WebStart and because it produces check sum for changes it saves bandwith and downloads just changed files.
A good tutorial : http://www.hascode.com/2012/05/creating-updatable-java-applications-using-getdown-and-the-getdown-maven-plugin/
Project website : https://github.com/threerings/getdown
Deployment in an multi-platform environment is always a big source of troubles. It think that the optimum solution would target the creation of native packages for all platforms, like RPM, DEB or MSI ... the ones that could be installed unattended also.
Developers should work on making the application self-healing and run without installation.
Doing so will payoff in minimize the deployment efforts.
I know this is not quite a solution as you where asking but sometimes you may get better results this way.
Remember that you'll get free updating service on Linux if you follow these.
I still hope Microsoft will add something similar to MSI (and that would not require you to register at them). Meanwhile for Windows you can take a look at Google Updater just released as open source - http://code.google.com/p/omaha/
They released a similar product for Mac OS http://code.google.com/p/update-engine/ but sad that they didn't think about creating one product from these two.
You can try the SetupBuilder Gradle Plugin to create a native *.msi installer with a simple Gradle build script.
It is free.
Supports 32 bit and 64 bit Windows. Also Linux and OSX.
Bundle the Java VM under Windows and OSX, does not required a preinstalled Java VM.
Can run Java Code before or after the installation.
Can create a windows service/daemon.
Has not a GUI but use Gradle. If you already use Gradle as build script language then it is very easy.
you may be interested in launch4j
Jonik, thanks for posting such detailed feedback of your experience. I wanted to write a follow up answer, since you raise some good points.
After certain base requirements are met (which unfortunately InstallAnywhere does not any more) there are not really 'bad' or 'good' tools, but rather tools that are better suited for some projects. It seems you studied carefully all options and install4j will work better for your project. This is probably a good choice, since you have an existing Java codebase from your previous installer that you want to reuse (though I would like to think some of that code would not be necessary with InstallBuilder :)
Regarding InstallBuilder, we support customizing the screen sequence using the <insertBefore> tag (we probably should better document this). It is also straightforward to bundle a JRE (just including the java/ folder in most cases) but I think your criticism is valid: since this is a common task we should do a better job at documenting / making it accessible though the GUI, including drag-and-drop in all supported platforms. We already have in our roadmap improving the GUI in the areas you mention. The funny thing is that a lot of our customers find the XML format so easy to use that they prefer editing it using their programming editors (as if they were editing HTML)
Finally, regarding licensing, our current model does not require purchasing additional licenses if those extra programmers will just be building the installers (not designing them) or purchasing extra licenses for build or continuous integration machines. In any case, a couple of floating licenses for install4j are more expensive than a full Enterprise Site license for BitRock:)
Thanks again for the feedback
I recommend having a look at cmInstall, which can be found at
http://sourceforge.net/projects/cminstall/
It meets almost all your requirements and it's open source. Plus I'm one its developers :).
[yes] Must support running custom Java code as part of installation procedure
[yes] Must support Windows, including latest 64-bit versions like Windows Server 2008; support for other target operating systems is a plus
[can be easily done by using 3rd party libs- e.g.:Tanuki Software] Must be able to install a bundled application server (such as Resin or Tomcat) as a service on Windows
[yes]Must support basic stuff like copying and moving files around, editing configuration files, extracting ZIPs, etc.
[yes - or you can programatically download & unzip it ]Must support bundling a specific version of JRE; at the very least by including a ZIP to be extracted
6.[no - it needs jdk 1.6 installed, support for .exe or .msi is planned for future]Preferably does not depend on a preinstalled JRE (or any other 3rd party runtime environment or library) on target machine; in other words, can produce an independent Windows .exe (or .msi)
[yes] The tool should preferably be cross-platform so that installer development can be done on Linux, Windows, or Mac.
7.[no - the cminstall framework is "developer based" - but easy to use.Just read the tutorials from http://sourceforge.net/project/showfiles.php?group_id=250019&package_id=305489 and see how easy it is to build an installer!] Should preferably have a decent GUI for putting the installer together. Once that is done, however, it must be possible to skip the GUI and make installer building part of automated build process.
I have also reveiwed few of the open source multi platform installers. Here is my comment:
BitRock InstallBuilder: Only Great for free and open source developers as it gives free license for use in open source projects.
InstallJammer: Good free and open source multi platform installer. Only one concern that as soon as one downloads the executable build from InstallJammer, the anti-virus program will immediately delete it. Somehow files built from InstallJammer are being caught as False Positives. You will have to work a bit more security certificate before publishing.
Izpack: Good free and open source multi platform installer. It may be a bit cumbersome for people not used to with ant. May be great when used with GUI front-ends like PackJacket.
I've seen several people recommend IzPack, but I honestly don't know if it meets your requirements. It's at least free :)
Sun offers an open source installer:
OpenInstaller
I'm sure that all your requested features are supported.
But it seems for me a little too hard to configure.
But guess what: It has not only a GUI but also a (pseudo-graphic) CLI.
Nice screenshots and info here.