Java 7 update 25 makes our java web start application fail with no logging

Question

Since the java 7 update 25 launched by Oracle our application no longer functions.

Initially we got some warning about codebase & sercurity tags missing in the Manifest file, which we fixed.

The problem we now end up with is that in the Console we only get the following lines:

#### Java Web Start Error:
#### null

We also get an application Error dialog with the message: Unable to launch the application.

The details button gives the following details in the Exception:

java.lang.NullPointerException
    at com.sun.jnlp.JNLPClassLoader.getPermissions(Unknown Source)
    at java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at desktop.DesktopProxySelector.<init>(DesktopProxySelector.java:24)     <- code smippet below
    at desktop.Main.main(Main.java:139)                                      <- code smippet below
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.sun.javaws.Launcher.executeApplication(Unknown Source)
    at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
    at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
    at com.sun.javaws.Launcher.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:724)

The relevant code parts are:

Desktop.Main.main

/**
 * Main method, starts the application
 */
public static void main(String[] args) {
    System.setProperty("java.net.useSystemProxies", "true");

    //Logger.getLogger("httpclient.wire.header.level").setLevel(Level.FINEST);
    //Logger.getLogger("org.apache.commons.httpclient.level").setLevel(Level.FINEST);
    java.net.ProxySelector.setDefault(new DesktopProxySelector(java.net.ProxySelector.getDefault()));

(The last line is line number 139)

desktop.DesktopProxySelector:

public class DesktopProxySelector extends ProxySelector {

    public  DesktopProxySelector(ProxySelector defaultSelector) {
    URI httpsUri = new CentralConfigurationService().getCentralLocation();

(The last line is line number 24 where the exception occures)

Can someone give us some clues hints (or better a solution) for this new behaviour of java caused by this 'minor' update.

When we run the application straight from the cli using java -jar Desktop.jar the application wil run file, so the issue has clearly something todo with the changes in java web start.

@trashgod: the error clearly has something to do with the Permissions change in 7u25, since the NullPointerException occurs in com.sun.jnlp.JNLPClassLoader.getPermissions.

Just to explain what I think happens (I am a colleague of Wouter): desktop.Main instantiates a desktop.DesktopProxySelector (our class), desktop.DesktopProxySelector instantiates desktop.configuration.CentralConfigurationService desktop.configuration.CentralConfigurationService instantiates a java.net.URI.

On the first line of the DesktopProxySelector init where the CentralConfigurationService is instantiated the getPermissions method, called by the JNLPClassLoader, throws the NullPointerException. So something is going wrong while loading the CentralConfigurationService class by java webstart with getting the permissions for the class. Could that have anything to do with the fact that a URI class is instantiated, which requires extra permissions (a connection to a remote uri is setup)?

Answer 1

Eventually the problem was solved. The problem was caused between a mismatch in the included jar files in the main MANIFEST.MF file vs the jar files mentioned in the launch.jnlp.

Apperently it is now required to have all jar files that will be used also be present in the launch.jnlp file.

(In the past it was decided to keep this file manually in sink, which obviously was not always maintained in a propper way. Now this process is automated, so the problem should no longer happen to us.)