Since Java 7 update 25, I have an issue where my client Java application, downloaded with Java Web Start, can no longer connect to a remote server. (The client uses remote EJB to connect various servers). The issue I believe is that the client application is being blocked by security features of this Java update.

A very quick (random?) fix around the problem is to show the Java console. If the Java console is enabled to be shown, the client application can connect fine.

I have defined the Codebase and Permissions in the manifest of the client jar's we build ourselves. I believe this has worked as we no longer see "Missing Codebase manifest attribute for...." in the console for our own jar's. However, the application still cannot connect out. I'm stumbling around somewhat on this issue and trying various things in an attempt to get this to work. Assuming i'm on the right lines and the problem is some jars missing the Codebase and Permissions in their manifests, my question is, should I and how can I modify the manifest of 3rd party jars to include this information? For example, the client app requires many JBoss and EJB client jars - do I need to somehow modify the manifest of all of these jars to include the codebase and permissions?

It goes without saying that all the jars are signed - the application would not start at all if there was a problem here. So the application starts with it's login box - but it simply cannot connect out to the servers.

If anybody can offer any help on this issue i'd be most grateful. As a quick fix, is there a way to get this to work via adjusting Control Panel settings (other than showing the console)? I have played with a lot but not stumbled on a way to get this to work other than showing the console, although ideally i'd like to be able to get this to work without having to do any tweaks to clients Java control panel.

Have similar problem: client-server application (swing-spring+hibernate). application crashes unless "Show console" is selected in control panel in Windows XP -- seems to be working on OSX with jdk7u25.

It's hard to tell if my solution fits your problem, but here goes. My JWS application started having ClassNotFoundException problems after 7u25 update. The problem was that the AWT thread had a different class loader than the main thread. I solved this by:

inside and at the beginning of the AWT-thread's life. You might use SwingUtilities.invokeAndWait. In my case, I knew when the first AWT-thread action was occurring in my application, so it was easy.

The apparent issue is that JWS sets the thread context class loader differently if you start the AWT-thread than if it (JWS) starts the AWT-thread when the Java console is showing. Maybe something about the delay. IMO, this is a JWS bug.

I can confirm that this hack solves problems I was seeing, including null java.util.logging root logger, errors setting look and feel, and class loading problems in general. It is better than than the 'Show console' hack we've used the last few days.

To expand on your description in case it's helpful to anyone, the EventDispatch thread that runs for the Web Start app seems to use the ClassLoader reference from the Web Start launcher instead of a separate one for the application being launched. This would actually seem to be a security problem.

Before the hack, I get the following output at runtime regardless of 'Show console' setting.

Current thread's ClassLoader is: com.sun.jnlp.JNLPClassLoader

AppContext named javawsApplicationThreadGroup's ClassLoader is sun.misc.Launcher$AppClassLoader

AppContext named javawsSecurityThreadGroup's ClassLoader is com.sun.jnlp.JNLPClassLoader

In other words, EventDispatchThread that runs for your Web Start app has the ClassLoader from javawsApplicationThreadGroup and doesn't get the correct ClassLoader for the AppContext it is running in. The hack above (thanks very much by the way) corrects it to have the one for your own application class loaded by Web Start.

Also in case it's helpful to anyone else, where it says Main.class.getClassLoader() in the code posted above, that should just be the containing class name that holds this whole quickAndDirtyFix... method.

As far as I can see, problems resulting from this j7u25 classloader change are reproducible only on Windows, not on OS X. Anyone made any experiences on Linux? So would it make sense to add an operating system switch to the if statement (System.getProperty("os.name") …)? And, yes, thanks for this workaround!

I have found that apps launched using the 7u25 Java Web Start but running under a Java 6 JRE (i.e. one is enabled in the Java control panel and the JNLP prefers it) will show the same symptoms regardless of whether the console is visible. In fact we developers have been completely unable to reproduce the bug otherwise; this is very helpful for debugging but it also means renders the fix above (thanks a ton by the way!) will not work; this can be remedied by changing the check on the first line to:

if (!"javaws-10.25.2.16".equals(System.getProperty("javawebstart.version"))) {

This will apply the fix whenever you're running under java web start 10.25.2.16 (the version that came with 7u25) regardless of the actual JRE being used.

1) Has anybody written a simple, self-contained example test case that demonstrates the issue? (I have, sort of, trying to trim it down further)

2) Has anybody filed a bug report with Oracle?

I'm willing to do both if nobody else has - just trying to avoid duplication

- Run the example above under Java 6 (either by disabling the Java 6 runtime in the control panel or by forcing Java 6 from the JNLP descriptor)

You'll get a UIDefaults.getUI() failed error.

This also happens to some users with only 7u25, but I haven't been able to determine what the specific condition is that triggers it and why it doesn't happen for everyone; we have two machines here with 7u25, one exhibits the problem and the other doesn't and I haven't been able to determine any differences in the setup of the two. Any insight here would be very much appreciated. For these cases, enabling the Java Console in the control panel fixes the issue, so make sure the console is disabled before you try it.