Java Web Start broken since JDK 1.7

Question

HERES THE ANSWER: It appears (through our testing) that Java 7 Web Start requires you to host your resources on a server using an SSL certificate. Your cert does NOT have to be signed, but unsigned certs will prompt the client with a trust message that they can ignore. See the below answer for more details

We have an internal application which we have been using for many years now. In order to make maintenance easier for this application we have not provided an installable version of the application to our employees, we simply give them a link to a .jnlp and use JWS to launch it on their box. This has thus far worked fantastic, but as soon as any of our employees update to Java 7 the JWS system stops working on their computer. We have checked, rechecked, and even validated our JNLP schema and it's fine, which leads us to think there is an issue with Web Start itself.

When the user clicks the jnlp file, it launches the Java 7 splash screen, which then begins to download the resources we need. From there it simply hangs and the progress bar on the JWS launching app remains at zero percent.

Any ideas? It is very much caused from the fact that they upgrade to Java 7. In the mean time we have advised that all employees are to remain on Java 6 until further notice. All of our code is properly signed.

Here's a copy of our JNLP:

<?xml version="1.0" encoding="utf-8"?> 
<jnlp 
  spec="1.5+" 
  codebase="http://peiportal/updater">
  <information> 
    <title>PEI Portal Application</title>
    <vendor>Petz Enterprises, Inc.</vendor>
    <offline-allowed/>
  </information>
  <security>
      <all-permissions/>
  </security>
  <resources>
    <jar href="PEIPortalLauncher.jar"/>
  </resources>
  <application-desc/>
</jnlp>

Answer 1

We encountered this problem also but fix was that the ServerName and AliasName in our Apache config file included the port number. ie domain.com:443. When Java 7 compares the ServerName it does not match and the problem occurs. By removing the :443 from the name all is well.

Answer 2

We recently ran into this issue when people started installing Java 7 on their Windows boxes. We have instances of jar files on three different linux servers, and found that we could download the application from two of them, one remote and one local, but not the third, also local, server.

The key was in the codebase specification in the jnlp file. In order for the jar file to be successfully downloaded to a Windows box running Java 7, the codebase had to specify "https:..." rather than "http:...".

The remote server cited above is set up as a secure server, and so was specifically set up with https. Neither of the local servers are set up securely, but the one that worked just happened to use "https:" in the codebase specification. Changing the jnlp on the other server made it work as well. (Our jnlp is templated, and modified for each install outside of source control, hence the potential for differences.)

You may need to delete any non-working Applications listed in your Java Control Panel to synchronize with the new jnlp on your server: go into the General tab of the Java Control Panel (available from the Windows Control Panel), press the "View..." button under "Temporary Internet Files", and delete any non-working Applications.

Answer 3

We had a similar issue after 1.7 update, but were able to solve by escaping the characters in the .jnlp file for href, i.e., by changing question mark and ampersand in the href value with &#63 and &#38 respectively.

href="appname.jnlp?protocol=http&host=xx.xx.xx.xx&port=xx"

This approach will be little safer, if the 1.6 is deleted after 1.7 update, and keeping spec value to "1.6+".

Answer 4

While grw's answer is definitely correct, I worked around this problem by forcing 1.6 in my JNLP file:

  <resources>
-    <j2se version="1.6+" java-vm-args="-Xmx256M"/>
+    <j2se version="1.6" java-vm-args="-Xmx256M"/>

Use the second line in the patch above, without the plus. That should force Java 7 to download the files using a Java 6 JRE, which will then work.

Answer 5

When the user clicks the jnlp file, it launches the Java 7 splash screen, which then begins to download the resources we need. From there it simply hangs and the progress bar on the JWS launching app remains at zero percent.

FWIW, this can also be caused by a deadlock in Webstart which is only resolved in 7u10 (as of yet still in beta). See http://javafx-jira.kenai.com/browse/RT-25023. The deadlock seems to be between the GUI thread (e.g. for Java console) and a jar downloading thread.

Answer 6

For anyone who hasn't got access to the kenai.com link provided by deepc: The bug mentioned is

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191454

Another bug I found in the Java bug DB that might match by description could be

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040

Hopefully Java Web Start will work over HTTP again with u10 …

---

Update: In our case it turned out that AVG antivirus was the cause. In the AVG settings, disable both "Online Shield" and "Surf Shield", and the combination of Java 7, Windows 7 and plain HTTP did work. Or upgrade to the latest AVG 2012 version. Cf. http://forums.avg.com/in-en/avg-forums?sec=thread&act=show&id=216448.