Java Web Start broken since JDK 1.7

Asked 8/3, 2012 at 19:47 Answered 6/11, 2012 at 4:6

Solved java jar jnlp java-7 java-web-start

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>

Widower answered 8/3, 2012 at 19:47 Comment(9)

Have you tried fully qualifying the hostname (peiportal) in the codebase? It's probably not that simple, but just a thought. – Capriccioso 8/3, 2012 at 19:54

Congratulations for the good experience so far. Not everyone remembers webstart positively. Please post the exception from the webstart window. Have you tried the spec="6.0+"? You should add an attribute href="http://peiportal/updater/path to jnlp file" to the jnlp element. – Loggerhead 8/3, 2012 at 19:57

The j2se and application-desc elements are also missing. I think the 1.5 spec has gone deprecated. – Loggerhead 8/3, 2012 at 20:4

Also note: Java SE 7 hasn't been released for end users yet, just for developers: java.com/en/download/faq/java7.xml – Naevus 8/3, 2012 at 20:5

Be sure to check the JNLP using JaNeLA. For the moment, specify the version string (in the missing j2se element) as 1.6*. For more details, see Java Web Start - Runtime Versioning. – Coauthor 10/3, 2012 at 2:8

Java 7 Web Start now requires you to host your resources on a server using an SSL certificate -- Could you provide a reference for this requirement? – Hitchcock 11/6, 2013 at 20:46

This was found through personal testing, Ill change the answer to be more clear about that – Widower 12/6, 2013 at 0:41

I have found it very helpful to enable the Java console and set logging to be as verbose as possible. I still had to look at the Java Webstart source (them available from Sun) to understand exactly what happened from the log messages. You might find this approach useful too. – Daina 3/7, 2013 at 20:21

We have continued to use HTTP (non-secure, no 'S') webstart through the transition to Java 7. I believe the reason you have found no message saying it is required because it is not. Perhaps you ran into a temporary bug that has been resolved or perhaps some other aspect of your environment requires it. We deploy several web start apps to the general public via http to Java 7 clients just fine. – Oster 29/7, 2013 at 20:10

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.

Adversary answered 16/8, 2012 at 14:11 Comment(1)

that is EXACTLY what the problem was. We have been looking everywhere for this solution and no where has it marked that they changed web start to require SSL when downloading it's resources in Java 7. Hopefully others will see this and get the solution now, thank you. – Widower 16/8, 2012 at 18:50

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

https://bugs.java.com/bugdatabase/view_bug?bug_id=7191454

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

https://bugs.java.com/bugdatabase/view_bug?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.

Mountford answered 15/10, 2012 at 7:33 Comment(0)

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.

Stephanotis answered 6/9, 2012 at 12:16 Comment(5)

I just tested this out and it does appear to work, however I want to point out the caveat that you will still have to have a 1.6 JVM installed in order to actually get it to run (obviously). Thanks for the heads up though, we had not been including the aforementioned line and as such we hadn't even explored this route. – Widower 6/9, 2012 at 16:18

I believe the Java 7 vm will install the correct version if you ask for it with the line above. I'm not sure of that, but pretty sure. – Stephanotis 6/9, 2012 at 20:34

from the way I understand the schema it will if you add the following href attribute: href="java.sun.com/products/autodl/j2se" Heres where I have found the most valuable information: mindprod.com/jgloss/jnlp.html – Widower 7/9, 2012 at 0:23

@RyanShillington I just confirmed that 1.6 JRE will be installed. – Hitchcock 19/11, 2012 at 15:53

@RyanShillington but that it installed an old version... 6.0.0_105 (!) – Hitchcock 19/11, 2012 at 16:11

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.

Ideogram answered 6/11, 2012 at 4:6 Comment(0)

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.

Limoli answered 5/10, 2012 at 9:47 Comment(1)

sounds like it could very well be the issue. We moved to SSL and resolved it, but this could be the root of why it doesn't work over unsecure connections still. I'll upvote, but I don't have any time to test this right now...still good information to have here for anyone else having a problem with earlier releases of Java 7, so thanks! – Widower 5/10, 2012 at 16:20

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+".

Phaidra answered 18/10, 2012 at 20:36 Comment(0)

Recommended topics

Hot tags