Both these applets run just great on any other browser, but Mozilla stops short. Both of these applets try to load jar or class files form the server, but evidently fails in loading the files. This is probably a duplicate bug (although I couldn't find any dupes), but this has not been working for a long time (if ever) so I'm filing this just to make sure you guys know of this. I NEED my Robobombo! I get these error messages: Robobombo: java.lang.ClassFormatError: game/Game (Local variable name has bad constant pool index) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at sun.applet.AppletClassLoader.findClass(Unknown Source) at sun.plugin.security.PluginClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.applet.AppletClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.applet.AppletClassLoader.loadCode(Unknown Source) at sun.applet.AppletPanel.createApplet(Unknown Source) at sun.plugin.AppletViewer.createApplet(Unknown Source) at sun.applet.AppletPanel.runLoader(Unknown Source) at sun.applet.AppletPanel.run(Unknown Source) at java.lang.Thread.run(Unknown Source) LOC: java.lang.NullPointerException: string is null at sun.java2d.SunGraphics2D.drawString(Unknown Source) at org.rubberbrain.games.loc.Chambered.redrawMessages(Chambered.java:139) at org.rubberbrain.games.loc.Chambered.addMessage(Chambered.java:161) at org.rubberbrain.games.loc.Chambered.init(Chambered.java:44) at sun.applet.AppletPanel.run(Unknown Source) at java.lang.Thread.run(Unknown Source)

This can happen when nonstandard compilers generate debugging information for unused variables. In this case the variable lifetime information is invalid and this is what the class loader is complaining about. If the class is a remote class all you can do is ask the owner to compile it without debugging information as their compiler is incompatible with Java 2.

I do know the owner of the LoC applet, and he uses the Java 2se 1.3.1 SDK, and compiles without debugging info. The applet works just fine on IE which has the old 1.1.8 (or thereabouts) JRE. This definitely has something to do with Mozilla, be it a bug or more demanding requirements of some sort.

some new information concerning the LoC applet: first of all it doesn't work in Netscape either, unlike I first said. (but Robobombo still does work in NS 4.75 but not Mozilla). What Xiaobing said might be true for Robobombo, I do not know what compiler they use and I can see it's a different issue now. The new info on LoC is that the classfiles are loaded just fine, but the images aren't. Mozilla is trying to find the images from the codebase, but doesn't look inside the jar file. IE finds the images just fine, and the applet also works in Mozilla & NS when the images it uses are placed in the same directory with the jar as separate files. See <a href="http://www.theintraclinic/locnew">LoC</a> for the example. Is this a Mozilla bug at all, or is it nonstandard behaviour on IEs part? (is someone actually reading what I'm saying?)

This sounds like a Java plugin bug/feature. Reassigning to the correct module - OJI.

changed URL of LoC to one that still has the pictures in the jar. The current version has them as separate files for now.

I concurr with Xiaobin's astute assesment. Woefully, the applet needs to be recompiled. Updating bug 62025. WONTFIX

SPAM: reassigning OJI bugs to new QA, pmac. (227 bugs)