Folks,
I have the following challenge, I would like to deploy an Applet which relies on Java 1.8 syntax into hundreds of client workstations already running an old Java Applet which relies on Java 1.5
The problem is, I do not have access to the Java 1.5 Applet code and even not to it's launcher Html page. Alas, this launcher Html page relies on the Applet tag and will therefore attempts to load the most recent Java plugin version installed on the workstation.
I don't like to rely on any virtualization solution, I have to run as a Java Applet, perhaps Web Start can be considered if you think it would help.
My questions are:
Is there a local workstation configuration/hack to tell the browser to load a specific (old) Java version when rendering the Applet tag ?
Otherwise, is there a way to use Java Web Start to workaround this problem and somehow run my newer Java Applet without updating the "official" workstation Java plugin version ?
Ok you ask several questions, here are some answers:
It is not possible to run Java 1.8 code with a "lower" JRE/JDK like 1.7, 1.6 or 1.5. The other way around however is possible - you can use Java 1.8 to run a java 1.5 applet...
You don't need to hack your workstation - if you only install one java version (even if it is an older one) and it is installed/configured correctly that version will be used to start your applet
With the next generation plugin (introduced since 6u10) it is possible to start your applets with a jnlp file. The jnlp syntax allows you to specify a specific java version and if that one is not installed it will/can be downloaded. One example would be:
<j2se version="1.6.0_10" href="http://java.sun.com/products/autodl/j2se"/>
Some general idea, please correct me if I didn't fully understand you:
You want both applets to run, right?
For that to work you will have to change something at some point. Possibilities (My answer disregards security - from this perspective always use the latest java version):
Install the latest Java 1.8 and sign your old applet. Signing an applet doesn't require the source code - just access your webpage, run the applet and then search java cache for the applet.jar. Sign it with an official certificate and deploy it on your server. (Additionally this may require adding some Manifest attributes as well)
Downgrade your new applet to java 1.7 or 1.6 and install an older Java like 1.7.0_17. Until Java 1.7.0_21 signing was not mandatory. If you see the baseline for Java 6 it would be version 1.6.0_43.
Theoretically you can use jnlp to define an exact java version which should be used to run an applet. The problem is, that it was introduced starting with 1.6.0_10 - thus your 1.5 java does not suffice. If it is possible to run your old applet with a slightly newer java and also add a jnlp file to your webpage then it could work. For that you would need to: Install two newer java versions: One 1.6.0_10 or higher (until 1.6.0_43, or 1.7_17) and the latest 1.8.0_X. Then in the jnlp file define your exact 1.6/1.7 java. When accessing your web page the 1.8 plugin will be started which detects that an older java version is required and then the older version will be started afterwards. For your newer applet the latest java will be used...
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'm new to java programming and I haven't used any java IDE,
I intalled Java JDK 8 on my computer and been doing some coding through Notepad++ and compiling it via cmd commands.
Since now that i'm comfortable coding manually, I wanna try to use IDE and decided to get the latest "Eclipse IDE for Java Developers". what I got is actually a .zip file no installation or something which is odd.
My question is does the eclipse uses the JDK I installed on my computer or it has it's own? if so how would I know which version of java does my eclipse run?
and if does use the JDK on my computer, if I want to update the JDK intalled on my computer do I have to uninstall the old one or I can just overwrite it with the new JDK build??
Thanks,
CC
Eclipse uses externally installed JDKs to run itself (it's written in Java, after all) and to provide the core libraries for the code you write (such as the java.* packages). By default, Eclipse will use its own compiler, ECJ, that has deep integrations with the IDE to provide features such as detailed error reporting and sometimes even partial compilation of invalid classes.
It's possible to override the compiler via some plugin (for example, you can explicitly specify a compiler in a POM via m2eclipse, though the default there still uses ECJ), but that's uncommon if you're still compiling Java code.
Eclipse has support for using multiple JDKs, for example for different versions (maybe you have backwards compatibility with 1.6) or different vendors. Depending on how your OS is set up, if your main JAVA_HOME is set through a symlink, you may not need to update Eclipse at all if you perform a minor upgrade. In the case of a major upgrade, though, you will probably need to go to "Installed JREs" and add or modify an entry.
1.the jdk you installed in your computor is global situation. it can effect anywhere if you have configured the environment variables.
2.configured the environment variables,run cmd like this,the java version will be show,enter image description here
3.generally, one JDK , one computor is enough.if you want to update jdk, just download new jdk and override the old jdk .
I created a java desktop application using net beans in java version 8 environment. The application is running successfully in my machine. But if i try to run the application in a computer which is having java 7 or lower, it is throwing Unsupported major.minor version 52.0 error. What changes i have to make so that the application runs on other versions without errors? Do i need to develop the whole application again using lower versionof java?
With a bit of luck, you just need to recompile your code with a lower jdk version.
But, if you have used new technologies (Lambda's, ... ), yes, you will need to re-write certain parts of your code.
In NetBeans:
Right click on your project
Click on Properties
Go to Sources in the Properties window
Change Source/Binary Format to JDK 7
Make any changes in your code, necessary to make it compile
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.
I have 2 separate Java installations on my machine. I have 5.0 to support an older Enterprise app I develop on, and I have the latest JVM installed for other things. I need to keep the old version on my machine, but I am now trying to use Play! 2.0 for some of my own projects.
When I try to run it from the Play! directory I get a "UnsupportedClassVersionError" since the 5.0 version is getting picked up. What is the best way to point play to my 7.0 jdk installation? It is important that JDK5 remain the default.
The play executable you run is a launch script that starts sbt with the Java version that is on the path. You can either change the path when you start it, like so:
PATH="/my/jdk7/path:$PATH" play
This assumes you are using some kind of unix shell. If you aren't, you can modify the launch script itself.
If you mean in production as in play start, you can run once you have compiled your application using play dist :
java -jar yourappname.jar
And thus specify the java version, you want to use;