Hot questions for Using Applets in java 8
Let me provide an example, Juniper's Network connect is a Java applet. This applet doesn't run from a ubuntu 64 bit OS with 64bit Java (JDK or JRE). To run this, their support site suggest to install 32 bit JRE.
Additional info: Verify Java applet - successfully verifies that the browser is able to run Java applets. Browser is 64 bit (Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 )
I am unable to understand the fundamental need for a 32 bit JRE when 64 bit JRE is already available ? Can some one explain this. This will help many.
In Windows- and *ix-systems there is no way to make a call from a 32-bit-executable to a 64-bit dynamic library (.dll or .so). So there's two possibilities one might need to use a 32-bit-jdk:
- The application is getting called from a native 32-bit-aplpication like a 32-bit-browser
- The java-application contains JNI-calls to native libraries that are only delivered as a 32-bit-version.
With an applet 1. is the most likely reason - but from your edit it seems more like 2. in your case.
When using Java 8 update 162 and older in Internet Explorer, the applet loads and works as expected. When removing Java 8 update 162 and install Java 8 update 171 or 172, the applet errors with
ClassNotFoundException referencing the class listed in the code attribute of the applet tag. I don't see any reason for this in the 171 or 172 release notes or the 171 or 172 bug fixes. I'm using Windows 10 Pro version 1709 build 16299.371. The applet is signed with a certificate that is trusted and still valid. There aren't any exceptions in the Exception Site List and adding an exception for this site (it worked fine without one on Java 8u162) still displays the exception. Using Java 8 update 162 and older is still working on another PC.
When clearing the Application cache in the Java configuration, the applet's JAR file doesn't appear again in the cache.
Are you aware of any changes in Java 8u171 or 172 that affect applets? Do you have any suggestions to resolve this?
Update 1: I'm aware that applets are deprecated in Java 9 and that applets don't work in Firefox and Chrome, but this is in Internet Explorer.
Update 2: I'm also aware that the 3DES Cipher Suites have been disabled in the update to 171 and 172, but the current digest algorithm is SHA-256 and the signature algorithm is SHA256withRSA with a 2048-bit key, which matches the signing certificate's signature algorithm and key. I've even tried signing the applet using Java 8 Update 172 without altering
java.security to remove 3DES_EDE_CBC and using that version the
ClassNotFoundException still persists as expected.
Update 3: When using Fiddler 4 or Charles as a proxy for Internet Explorer and capturing traffic between the server and the browser, the applet loads and works as expected. Both the Java SE Runtime Environment 8 Update 172 and Java Plug-in 11.172.2 Add-ons are set to Allow on all sites. When I clear the applet from the Resources cache using the Java Cache Viewer in the Java Control Panel, the applet doesn't download in the cache again without the proxy, but if I use a proxy again then it does download into the cache. My guess is that the proxy traffic is being treated as local and so has different permissions. Any other ideas or what permissions it could be?
Update 4: Enabling the debugging options in the Java Control Panel causes the full stack trace to show, where CODE_ATTRIBUTE_VALUE is the value I set on the code attribute of the applet tag. The applet's JAR file doesn't seem to be downloading even though I list it in the archive attribute.
java.lang.ClassNotFoundException: CODE_ATTRIBUTE_VALUE at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source) at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
The Java Console now also shows more details about the connection and I see the following which is the cause:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source) at sun.plugin.PluginURLJarFileCallBack.connect(Unknown Source) at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source) at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source) at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$900(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source) at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source) at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source) at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source) at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.io.EOFException: SSL peer shut down incorrectly at sun.security.ssl.InputRecord.read(Unknown Source) ... 40 more
Currently the applet is hosted on Windows Server 2003 using IIS. Moving it to Windows Server 2008 also using IIS causes that problem to go away. Mr. Laitinen was right the TLS connection was using 3DES_EDE_CBC.
Update 171 adds 3DES_EDE_CBC to the list of disabled algorithms (jdk.tls.disabledAlgorithms). Remove it and your applet will work again.
I have Java 8 update 20 and I just made my first applet, but when I try to run it in the browser it says that my security settings have blocked it! After I go into my java settings and go in the security tab all I see it:
Enable Java content in the browser (It is a checkbox) Security level for applications not on the Exception site list Very high (RADIO BUTTON) High (RADIO BUTTON)
And then I have my exception site list... I am missing the Medium radio button? I can't run my applet without the medium option! I have tried adding my site to the exceptions list but it didn't work... I have deinstalled the previous version of java which was Java 8 update 11. What's the problem??? Thanks!
If I understand your question;
I am missing the Medium radio button? ... What's the problem?
Correct. You are missing the Medium radio button now. To quote the 8u20 release notes
Java Control Panel Changes
The Update tab in the Java Control Panel now enables the users to automatically update 64-bit JREs (in addition to 32-bit versions) that are installed on their system.
Mediumsecurity level has been removed. Now only
Very Highlevels are available.
You can develop with an applet viewer; you'll need to sign your code for security reasons.
From Deploying an Applet (The Java Tutorials) -
To deploy your Java applet, first compile the source code, package it as a JAR file, and sign the JAR file.
See Signing JAR Files for how to sign your Applet.
I have an web application from which multiple users loads a Java applet. Now there is a problem that the loadbalancer does not support TLS1.2 which is the default for Java8 and it seems that Java8 does not automatically try lower version.
How can I force the applet to be loaded using TLS 1.0/1.1? I have tried to put this into the <applet>:
<PARAM name="java_arguments" value="-Dhttps.protocols=TLSv1">
Any help is appreciated, not very keen on solution where hundreds of users need to configure their Java clients.
This the starting point from which this question was brought up: Java applet not loading on Java8/HTTPS
I have an web application from which multiple users loads a Java applet... How can I force the applet to be loaded using TLS 1.0/1.1?
The applet is loaded by the browser, not by Java. So it does not help to make any Java related settings here. These settings are only relevant if the applet itself communicates with the server. Edit: The download is done by the Java plugin. This does not affect the rest of the answer i.e. that the problem must be fixed at the load balancer.
Now there is a problem that the loadbalancer does not support TLS1.2
Unless the load balancer is broken it will negotiate to a lower protocol version. It is inherent behavior of TLS that both parties agree to the best version both support. But, there are broken load balancers out there which simply do not understand TLS1.2 or behave strange when confronted with larger packets which are more likely with TLS1.2 (older F5, long fixed).
Unfortunately, if this happens to be such an old broken F5 you might be out of luck because a bug in these load balancers caused the packet to be dropped, so that the connection would stay open until timeout. In this case most browsers do not downgrade to a lower TLS version, because they only downgrade on immediate errors like a connection close from the peer. All you can do in this case is to fix the broken load balancer.
I've made a simple java applet that literally only draws "Hello World". I've searched the internet for hours but nobody seems to know how to allow locally stored applets to run when Java 8 is installed. Any help would be greatly appreciated.
As an after thought this is my html file I'm trying to open in Internet Explorer:
<!DOCTYPE html> <html> <head> <meta charset="ISO-8859-1"> <title>My Applet</title> </head> <body> <h1>Hello World Applet</h1> <applet code="Main.class" width=150 height=25></applet> </body> </html>
with Main.class being my compiled applet file.
You can use the AppletViewer for testing and development. To run in a web-browser you will need to create a signed jar (because of security restrictions). From the linked Understanding Signing and Verification, Once you (or your browser) have verified that an applet is from a trusted source, you can have the platform relax security restrictions to let the applet perform operations that would ordinarily be forbidden. A trusted applet can have freedoms as specified by the policy file in force.
I have a java applet, which doesn't run on 64bit systems (browsers & OS are 64Bit) but works perfectly fine on 32bit Client systems. Why the applet fails to execute on 64Bit client system ?
There is no such thing as 32-bit Java applet.
Java sources are compiled into byte code which does not have a "property" of 32 bit or 64 bit. Only the JVM has variants of 32 bit or 64 bit.
So as long as your applet only contains Java code (and no native libraries), it should run on both 32 bit and 64 bit JVM's no matter what you used to compile your sources.
I maintain a few applets used for a website and Java 8u60 makes them just not fire. I'm not sure exactly what's going on.
Here is how I declare the tag for IE:
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"> <param name="code" value="com.mysite.myapplet" /> <!-- other params --> </object>
innerHTML property. Is there a workaround?
This is the workaround I found: use an
"But all the doc says to use
OBJECT for IE support?"
I know. But even Java's own deployJava.js outputs an
Apparently this is a bug specifically introduced in 8u60 which makes injected HTML
OBJECT tags inoperative.
So instead, inject this:
<applet code="com.mysite.myapplet"> <param name="classid" value="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" /> <!-- other params --> </applet>
That should work. Applets that fire automatically on opening the page can be left as objects.
I'm using java applet on my site. I want to provide correct applet tags which will work in modern browsers and in old IE versions (8+). As far as I understand, modern browsers use
<embed> tag and
<object> tag provides best experience for Internet Explorer. Internet Explorer even performs automatically silent Java installation, if user does not have installed Java without browser restart. That's very nice.
Now the problem is, most of the documentation regarding
<object> tag is outdated. My applet compiles with Java 1.6 and works fine with it, but obviously I want users to install the latest Java. I can't find official documentation about silent installation for Java 8. If I specify
classid="clsid:CAFEEFAC-0016-0000-FFFF-ABCDEFFEDCBA", probably that will install Java 1.6 and that's bad. I've found some urls for downloading
.cab files and there are no urls for Java 8. Did Oracle remove that convenient method for Java 8?
What is the best approach to use for embedding Java Applets with modern Java with Internet Explorer?
See the Java Rich Internet Applications Deployment Advice for details of the deployment toolkit script. It should write whatever applet tags are recommended for that user agent.
If I specify
classid="clsid:CAFEEFAC-0016-0000-FFFF-ABCDEFFEDCBA", probably that will install Java 1.6..
Not anymore. Oracle has dropped support for loading/using an older JRE. Apparently they have become sick of supporting older JREs with potential security bugs.