Last night a new Java 7 update has been released: 7u65. I have a web application where a service applet is loaded, and after the update, my tests on different PCs did not show issues nor wrong behaviors.
Later, I started to receive issue reports related to my product's Java service applet. All the reports came from users who updated Java JRE to 7u65 (from 7u60):
The applet was not loading at all. I display a "Loading" screen when the application starts, and this was not being displayed. Also, all the services provided by my Java applet were unavailable.
After changing the Java Control Panel's advanced configuration to always show the console (in one of the PCs where this issue happened), I discovered that the applet was not even launching the Java console.
Using the same station where the error happens, trying to access java.com to check the current java version, the Java applet is loaded and the console is displayed without errors.
All tests were performed after clearing Browser and Java Cache, and even after removing the installed certificates (mine is a valid signed applet).
I checked the Java 7u65 release notes and none of the mentioned changes seem to affect my applet. Also, there were no issues while using Java 7u60.
I don't have any clues about what is going on, perhaps because the java update was released hours ago. As the Java console can not be displayed even if I configure Java Control Panel to do so, I can not tell if there is any exception. I can not reproduce the issue in my PCs (Windows 8, nor Windows 7, both at 64 bits), but the issue has been reported on Windows 7 PCs.
One of my friends told me that this seems to be happening on machines where Java 7u60 was in use, and then it was updated to Java 7u65 with no deinstallations. Also, this tends to happen in older OS (ie: WinXP) which is more natural.
I write this question because it seems very odd that some PCs have this issue, and some others not. I'd like to know if any one else is having this issue, knows what could be the reason, or has discovered/applied any solution to it. Also, I'd like to share the solution if I ever happen to find it.
Thanks.
Edit:
External references, related to the same Java version (JRE).
Internet Explorer crashing after updated Java to 7u65: An issue with the same JRE version, this time with Internet Explorer and Firefox.
RS Loading Issue (Java) ~ READ: An issue related to the same JRE version update, this time, in a Java Game.
The future of Java on Windows XP:
This end of support announcement has been misread as "Java no longer works on Windows XP" or "Oracle will stop Java updates from being applied on Windows XP". These statements are not correct.
I just ran into this exact problem with one of my applets.
It looks like some changes were made to the handling of the 'java-vm-args' and 'java_arguments' params in 7u65.
'java_arguments' seems to no longer work, when it is specified, my applet will silently fail without even launching the JVM.
I have had the same problem.
I delete C:\Users\${USER}\AppData\LocalLow\Sun
When i reloaded the web page containg the appelets. The JRE recreated this folder again.
And evrything was OK.
There is no big difference between the folders contents .. but it worked.
It seems to be a bug in the jRE
It seems that oracle has changed something with processing default plugin java arguments,
that caused problem in new java.
When upgrading from older version of java it is possible that value for
deployment.javaws.jre.0.args (or deployment.javaws.jre.1.args)
is not defined in
C:\Users\${USER}\AppData\LocalLow\Sun\Java\Deployment\deployment.properties
If you add
deployment.javaws.jre.0.args=
to deployment.properties, applet will work.
It can be done through Java Control panel also:
Java -> View -> double click on Runtime Parameters cell for java 7u65 to enter edit mode -> OK -> Apply
java-jvm-args solution didn't work for me, applet was launched but arguments were ignored.
Oracle has released an update that resolves this specific issue via version 7u67
http://www.oracle.com/technetwork/java/javase/7u67-relnotes-2251330.html
As Miloš Ratković wrote, if customer hasn't string in deployment.properties
deployment.javaws.jre.X.args=
where x is number of java installation for version 7_65 (number of java installation for particular version is X in string deployment.javaws.jre.X.product=1.7.0_65), Java applet failed to start.
For my case I have a solution - don't pass any arguments for my applet.
In my javascript code for starting applet I'm just comment
<param name="java_arguments" value="some arguments">
string
Also, if you delete the directory C:\Users\${USER}\AppData\LocalLow\Sun, during next startup of java applet java write new deployment.properties with correct java args string
Uninstall java 7 update 65 and reinstall java 7 update 55 Download the windows x86 offline version
Go to Java control panel and uncheck: automatic update
When the next window comes up, click on "do not check"
then click on "apply" and "ok"
close all browsers and reopen them to continue your work
This has worked for me every time so far and I have been doing this for the last two weeks now with "0" issues.
Sorry, this is not the answer. I was trying to verify the feedback about JRE 7u65 not able to accept "java_arguments"; however, I setup a Windows x32 and installed (new) 7u65 without upgrade from any older version. With the "java_arguments", the machine is able to load the applet in IE8 and FF30, when few specific PCs do fail the same applet with upgraded u65.
Java Compatibility
I have been having some trouble with making a custom browser I am using a default class provided by oracle for a custom browser. One thing I noticed with the browser is that it cannot run java applets without some sort of variation of java browser plugins. How exactly do normal browsers receive information from a web server to run a java program externally? Is there any way to somehow point the browser toward the jre to run the app like on a normal browser. Just need somewhere to start. FireFox apparently references some sort of MIME format under the npjp2.dll native found in the jre directory. Thanks Very Much.
Oracle Example
You can provide the user with a standard html download page in order for him to download a JNLP file which is the standard file to start a java web start app (applet). If the user's system has java installed, it must recognize the .jnlp file and assosiate it as a java app. It's an extra step, for the user to manually download the file instead of running automatically on a web browser, however because of recent security loopholes on java web implementations, most browsers don't trust java anymore, therefore the blocking. If you insist on setting up a web start app in a browser you must make sure that all users have appropriate security configurations on ther java installation (very unlikely).
EDIT:
Here's a very nice tutorial on how to achieve what I just explained.
TUTORIAL
Is there a way to detect if java is installed on your machine or if java is disabled on the browser. We use java applets in our application but before the applet is loaded we use "deployJava.js". Sadly even if Java is disabled on the browser it says java is not installed.
So is there way to differentiate if Java is installed or Java is disabled, preferably using javascript. I have also tried using "navigator.javaEnabled()" but it gives me the same result as using "deployJava.js".
You can't.
And that would be very annoying if you could. There's already enough information leaking from the browser to the page, if it started telling people what I have installed but that I have ostensibly disabled, that would be very annoying.
I guess it could be possible and useful to envision an API for that, but in the current state there isn't any: either the plugin is here to be used, or it isn't. It doesn't matter whether it's installed or not.
I guess you'll have to work around it by stating in your user-facing messages that Java either needs to be installed or enabled. Or you could offer to download a diagnostic tool to run it and check it locally, that could be another working alternative, though with the obviously annoying extra-steps to perform (and an additional tool for you to support).
Add a redirect to the HTML page in question. Redirect to javaNotEnabledOrNotInstalled.html (but think of a less descriptive and silly name for it).
Early in the applet init(), call JS to cancel the redirect.
Note also that in the traditional applet element..
<applet
code=..
width=..
height=..
alt='Java is installed but disabled!'>
No Java Plug-In installed in this browser. Get Java free from..
</applet>
In this circumstance, if Java is not installed at all, the user should see..
No Java Plug-In installed in this browser. Get Java free from..
However if Java is installed but disabled, they should see..
Java is installed but disabled!
Here is something js window.navigator.plugin
In general, browsers (I see this esp. with Safari) are kind enough to inhibit a Java applet from running if it senses that a security related update for Java exists. It seems to do this quietly... my applet just "sits-and-spins" in the browser window - never executes. Is there a way, preferably via JavaScript, to programmatically determine whether or not this condition will exist (so that, for example, applet loading can be skipped and some kind of informational message can be displayed)?
In my particular case, my applet quietly did nothing when launched with Java 1.6.0_37 (on Mac OSX 10.6, Safari 5.1.7). As soon as I updated to Java 1.6.0_43, the applet ran without incident.
The best approach is generally to poll for the existence of the applet using Javascript, and take alternate action after a specific time.
Note that the Deployment Toolkit Script is intended to ensure a valid Java version and run the applet while providing feed-back to the user, so it would be a better overall approach to deploying the applet.
I am deploying a signed & trusted applet. We need to run the applet in a separate JVM & increase the heap size. Setting separate_jvm & java_arguments works on our local boxes. Curiously we have clients that though they are using 1.6.0_15 don't seem to be running the new plugin architecture.
When I check their Java config, "use next-generation plugin" is checked & IE7's option "use Java 1.6.0_15 for applet plugin" is also checked. Nothing seems obviously wrong. The Java console also reports the correct version, but neither separate_jvm nor java_arguments are respected.
Just as a sanity check we wrapped the applet in a JNLP & set up our web page to serve the applet with a jnlp_href. The applet tag had a bogus code parameter to ensure the JVM was actually running the JNLP. The Java console complains that it cannot find the bogus class when it should be properly loading the JNLP.
Are there security settings or something else that might cause what I'm seeing?
I'm afraid I've just a few suggestions rather than an absolute answer.
The Java virtual machine version
and plug in version can be
different. Go to Control Panel,
Java, Runtime Environment settings.
When you check the console it may
show the two different versions.
The new plugin architecture would
depend on browser, Opera doesn't use
it at all, for example. IE7 does
though. So check which browser it
works on.
Java has got corrupted due to
repeated installs and uninstalls.
Pretty common complaint I've found.
If you have control over one of the
machines you should uninstall every
Java. Restart machine. Install
latest Java.