Are the Oracle Java and OpenJDK implementations for com.sun.net.httpserver fully compatibile? Should I expect some problems when I develop on Oracle Java, but ship for OpenJDK (docker)?
Eclipse warns me for using 'restricted' package, which makes me some worries, however, Eclipse's warnings are flawed in many domains (maven the most prominent one from my daily life).
Is there a good reason as for current stand (Java 8) for discouraging using of this package in first line? If there is, is it relevant for Oracle vs. OpenJDK or they are fully compatibile for that package?
That package is part of an exported, JDK-specific API, per https://docs.oracle.com/javase/9/docs/api/jdk.httpserver-summary.html . Exported means you can use it. JDK-specific means it's in both OpenJDK and Oracle JDK, but doesn't necessarily have to be in every implementation. Please see http://openjdk.java.net/jeps/179 for details.
Related
This question already has answers here:
How can I get Java 11 run-time environment working since there is no more JRE 11 for download?
(4 answers)
Closed 3 years ago.
We are planning to migrate our Java 8 project to use Java 11. But I noticed that Java 11 doesn't have a JRE folder.
In Java 9 and Java 10, folder structures are changed i.e. java\jdk1.x or java\jre1.x, where x is Java 9 or 10.
But in Java 11, I am getting only one folder, i.e. java\jdk-11. How will my client use my application without jre?
What I understood is that Java 11 is enforcing to modularize our application, and using jlink is needed to create our own jre to run the application in client.
Is my understanding correct?
For 20 years, the JDK shipped with a JRE which was just a subset of its functionality installed in a different directory on your system.
In fact, it shipped with TWO identical JREs, one installed inside the JDK installation directory and one outside it.
This has always puzzled me as it's a complete waste of effort on the part of the maintainers to make this so, and a complete waste of disk space on the computer you install it on, as that JRE just duplicates some of the things the JDK can do already.
Finally, with Java 11, Oracle and the OpenJDK team decided to end this silliness and just distribute a single thing, the JDK.
This JDK when installed is actually smaller on your hard disk than the old JRE alone used to be, removing even the somewhat valid argument that you'd want a separate JRE for devices with limited disk space, an argument that never explained why 2 JREs would be installed with a single JDK in the first place but was made to justify the need for a JRE as a stripped down runtime environment for the JDK.
Ergo, there is no need for a separate JRE, and there hasn't been one for a long time, let alone for including and forcibly installing it as part of the JDK installation.
And no, you don't need to create your own JRE. Just install the OpenJDK on the client machines and make sure you add the $JAVA_HOME/bin to the system path, just as you had to do with old JREs.
And oh, strip the Windows directory tree of any java*.exe files which some versions of the old JRE installer were wont to place there, as well as the system path which also had some weird entries added by some JRE installers.
tl;dr
How will my client use my application without jre?
➥ Bundle a Java implementation within your Java-based app.
Learn about:
Java Platform Module System
jlink (JEP 282)
jpackage (JEP 343)
Details
What I understood is that Java 11 is enforcing to modularize our application
No, modularization is not required, strictly speaking. Most existing apps can run as-is in Java 11. You can continue to develop in Java 11 without modularizing your code. But in your case, for a GUI desktop or mobile app, then you need to package a JVM within your app. Modularizing and using jlink tooling is probably the best way to go about that. In contrast a server-side Servlet-based app or Microservices server need not yet modularize, though likely a good idea to do so eventually.
I noticed that Java 11 doesn't have a JRE folder.
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.
Some folks are disappointed to see the passing of the Java Everywhere dream. And they may be annoyed to have to make a build of their app for every host OS (macOS, Linux, Windows, etc.). On the other hand, some developers are happy to be bundling a Java implementation (now smaller than ever) with their app, as that eliminates the hassle for the end-user to download-install-update a system-wide Java implementation. Also eliminates wrestling with corporate IT departments to install Java on users’ PCs. And bundling Java with app simplifies testing and support, as you know and control exactly what version and distribution of Java is involved. By the way, this bundling-Java-with-app is not exactly new: It has been supported by Apple for many years in the macOS & iOS app stores.
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.
Here is a flowchart diagram that may help you finding and deciding amongst the various vendors providing a Java 11 implementation.
Look at the AdoptOpenJDK project website to download the latest JRE and JDK.
I have used their nightly builds to work around the problem of missing JRE in JDK package. Just unpack JRE into JDK folder and this is going to be it.
I regularly use MALLET for topic modeling in the classes that I teach. Running MALLET requires users to have the Java Development Kit installed. I currently have JDK 8 update 241 installed on my main computer, and I know that MALLET works properly in this environment. That said, JDK is now up to v14.
Which version(s) of JDK does MALLET support?
I'm not altogether sure that you do need the JDK. They never say that on the website. The tarfile that I downloaded already includes compiled classes - you aren't expected to build it from source - so the JRE should be enough.
Strangely enough, the compiled classes in the class directory are targeted at 1.7 (bytecode version 51) whereas the pom indicates that it's supposed to target Java 1.6. So it's quite probable that by rebuilding it you could support an older version of Java.
In any case, the JDK is backwards compatible by design. Any version from 7 onwards will be able to run it (6+ if you were to rebuild it).
Running it on a newer version will benefit from the new features of the JDK, such as improvements to the garbage collector, so you may see some performance improvement there. If you are not concerned about that then it doesn't matter.
I have a trial task which includes writing simple http server using only Oracle JRE 1.6 standard libraries. Here simple HTTP server in Java using only Java SE API
I found the statement:
Since Java 1.6, there's a builtin HTTP server in Sun Oracle JDK (note: JDK, not JRE).
But I thought that all runtime libraries are included in JRE, and JDK is JRE + some development tools. Also, I have downloaded JRE 1.6 and found that HttpServer is included there in the rt.jar file.
So, my questions are:
Is it correct for me to use this implementation?
Why it is stated that JDK has libraries that are not in JRE? Do JDK provide any additional libraries to JRE?
Before I answer, please note that I am not familiar with the implementation you're referring to (I generally pull in Jetty and embed it when I need an HTTP server in my modules). So I'll answer somewhat generally, but maybe this gets your mind thinking in a direction that's helpful.
Is it correct for me to use this implementation?
That depends on the constraints on the trial task. Assuming that the implementation meets those constraints, and you are willing to live with any shortcomings it has, then there is nothing intrinsically wrong with using it. If it's available, it's fair game.
Why it is stated that JDK has libraries that are not in JRE? Do JDK provide any additional libraries to JRE?
First off, the statement made in that question is observably false. Clearly that implementation is included in the JRE.
More generally though, the JDK always has the option to do this, and there are definitely libraries deployed with a JDK that are not deployed with a JRE (see this page). Moreover, depending on the install, it's possible that there are installed extensions to the JRE in place (see this page).
My question is if Java JDK and JREs have to be compatible to run?
I mean: will Java applications written using JDK version 8 in future work with current JRE's?
It is possible to use cross-compilation options when compiling. Do that and it will be possible to compile code with SDK 8 that is compatible with Java 1.1. It won't be very advanced code for 1.1, but it will run.
The short answer is No.
If you develop your application in JDK 8 and run it with JRE 7, you would get an UnsupportedClassVersionError.
This question is two part:
JDK vs JRE
forward / backward compatibility.
JRE is the acronym for Java Runtime Environment. JDK is the acronym for Java Development Kit: a set of tools which you use to develop Java programs. The JDK also contains a full JRE. In general there is no compatibility issue between the two. But you might want to take care not to use libraries which are only available in the JDK (for example code generation or the tools.jar)
Java itself is compiling to bytecode, which is forward compatible. That means you can use bytecode of any Java version and run it with any newer version. The other way around generally doesn't work and is checked by using the class file version ("java.lang.UnsupportedClassVersionError: Test : Unsupported major.minor version 51.0").
Then there are Java libraries, including the core libraries. So far there was never anything removed from them, so they are forward compatible. This is probably going to change with Java 9 where a very small usually unused library functions are removed.
Regarding to backwards compatibility, this is possible by setting the Java compiler to produce Bytecode of an older version. Up until Java 8, the compiler was always able to produce bytecode of the last two major versions as well. However, you might successfully compile a Java 8 source to Java 6, but not be able to run it. That is the case when you use libraries that are only available on a never Java. For such cases there is for example the maven animalsniffer plugin which will verify that when you compile against an older version, you actually only use libraries existing in said version.
I have a PowerMac and it is giving me bad version number on some .jars. I would love to make it seem like I am running Java 6. How would I spoof the version? Let me also say I am running PowerPC and Leopard
The most likely problem is that you have Java 6 JAR files and you are trying to run them on an old Java installation.
How would I spoof the version?
The answer to your question is that you can't. The way to run Java 6 specific JAR files it to use a Java 6 (or later) JRE or JDK.
The problem is that the format of Java class files has changed, and your installation can't cope with the new format. And this is not a gratuitous change that you can pretend doesn't exist. Java 6 (actually Java 5) has support for generic types, enums, annotations and other things. Assuming that the JARs contain code that uses these new language features, an older JRE simply won't know what to do with them.
There are two solutions:
Upgrade your Java installations to the required level on all machines. This is the best solution ... if it is an option ... because it means your users will get the benefit of security and bug fixes and performance enhancements. (And progress of your project won't be held back by the constraint of supporting legacy platforms.)
Compile all of your code for compatibility with the oldest version of Java that you still have to use. Either compile on the corresponding old JDK, or on a more recent JDK using appropriate -source / -target / -Xbootclasspath options ... as described by the javac manual page.
The catch with the second solution is that if the source code for the JAR files in question uses recently added Java language features or APIs, then recompiling for the older platform will fail. To fix this you will need to rewrite your code to replace the nice modern stuff with archaic stuff. Not a good solution, IMO.
The other possibility is that you are seeing corrupted JAR files. This is unlikely, but it can happen if you are using applets or webstart, and the server is delivering error pages instead of JAR files.
The third possibility is that you simply haven't configured your Mac's Java installation's correctly. Making Java 7 the default should allow you to run everything without class version problems. (Thanks #paulsm4) Note that I can't help you with that ... 'cos I don't use Java on a Mac.