Skip to main content

Java 6u12 class verification change

2 replies [Last post]
jimaltio
Offline
Joined: 2008-03-13
Points: 0

We have an applet that was working fine in 6u11 and an earlier 6u12 build, but has the following problem with the 6u12 release:

Once the applet is dragged out and creates a desktop shortcut you cannot launch the applet from the shortcut any more - it fails with the following exception:

java.lang.NoClassDefFoundError: netscape/javascript/JSException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at com.sun.javaws.Launcher.executeApplet(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(Unknown Source)

Which makes sense - the netscape JS classes are not available when launching the applet via WebStart. However in previous JRE versions it was enough to remove the relevant 'import netscape.javascript.*;' from the class declaration and use an explicit class reference instead, as all we are doing is catching a JSException.

Between Java 6u11 and Java6u12 the WebStart launcher has changed and now seems to be verifying that all classes referenced by the main class, whether via an import statement or an explicit inline reference, are available.

We can change our applet relatively easily in this instance, but it does have wider implications on class dependency verification. I did wonder whether it was related to this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6764974

Does anyone have any more information on whether this is a deliberate change or an accidental regression?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tackline
Offline
Joined: 2003-06-19
Points: 0

Removing an import and inserting fully qualified references to types should not change class files, and therefore not affect runtime behaviour. More likely there is a subtle change that causes the verifier to do slightly different checks. See item 44 of Bloch and Gafter's Java Puzzlers. The obvious solution is to keep code dealing with netscape.* clearly separated from more general code.

jimaltio
Offline
Joined: 2008-03-13
Points: 0

Thanks for the reply. You're right of course, the netscape class usage ideally shouldn't be in the main applet class, but it's also true that the applet worked fine until Update 12 was released, so whatever the change is it may stop other applets working when they did before.