My guess is that Webstart is placing the core libraries installed in the JRE into a different classloader than the application libraries. The JRE classloader can't "see" classes or other resources from the application. If you look back at your stack trace in the original message you'll see a bunch of ClassLoader stuff in the middle, which you correctly suspected to be part of the issue. But this is still pretty mysterious.

When you do a Class.forName() are you calling it just like that, or are you doing

SomeAppClass.class.forName()

or what?

If you look near the bottom of the stack trace, it's obviously finding JAI classes, so here is what I think is happening:

1. You call Class.forName() on the JAI class which causes it to be initialized. 2. This results in registering all the services, including the definition of those services/operators that are included in JAI ImageIO Tools, e.g. ImageRead/ImageWrite. 3. When THOSE JAI ImageIO Tools services are referenced, they reference back to JAI classes. But since they are in the JRE classloader, and if my theory above about the Webstart app loader is right, they cannot see the JAI classes which are in the application classloader pool.

This issue or related ones (specifically with J2EE app containers like Tomcat and Weblogic) have been very painful for us when dealing particularly with dynamically registered services such as ImageIO reader/writer plugins etc. In my opinion, the JAI extension needs to be installed into the system/JRE classloader rather than the application classloader, which MIGHT solve your problem. But then if you publish any services/plugins/operators to JAI, you might not see them load correctly due to the same issue.

Do my theories make any sense?

Mike