The purpose of this bug report is to document issues with migrating applets from N4.x to N6. To be most useful it should include comments from the OJI team, the Java platform team, and the mozilla js and caps teams. I'm copying someone from each. -jd

Many applets developed for 4.x are binary compatible with 6.0. Those that are not, suffer from one or more of the following changes: 1 class file format change; 2 java or browser api change; 3 security policy change; 4 unintended regression (i.e. a bug). One change that falls into the second category (api change) is the removal of the netscape.security package from the java runtime shipped with the browser. In fact, the security implementation has been completely reimplemented without including that package. JavaScript simulates the reflection of this package into the scripting environment, but the Java api no longer exists for use by applets. As I understand it, this package was used to talk to the browser security manager, to do things such as enable a capability. Without this feature, applets must depend on scripts to manage capabilities.

It was my understanding that applets no longer need to enable capabilities (the old netscape.security API), although we still do this in JS. Maybe we could add these functions back to Java to allow applets to enable privileges for JS...that could get complicated... I'm exploring ways to make the JS security manager more compatible with the Java 1.2 security implementation in the plugin.

Some applets compiled with older versions of javac need to be recompiled. Otherwise, you'll get a ClassFormatError, as in bug 65949. java.lang.ClassFormatError: symantec/itools/awt/StatusBar (Local variable name has bad constant pool index) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:486) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at java.net.URLClassLoader.defineClass(URLClassLoader.java:248) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:128) at sun.plugin.security.PluginClassLoader.findClass(PluginClassLoader.java:221) at java.lang.ClassLoader.loadClass(ClassLoader.java:297) at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:108) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) at sun.applet.AppletPanel.createApplet(AppletPanel.java:579) at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1157) at sun.applet.AppletPanel.runLoader(AppletPanel.java:515) at sun.applet.AppletPanel.run(AppletPanel.java:293) at sun.plugin.navig.motif.MotifAppletViewer.maf_run(MotifAppletViewer.java:127) at sun.plugin.navig.motif.MotifAppletViewer.run(MotifAppletViewer.java:123) at java.lang.Thread.run(Thread.java:484)

This is with reference to #65949. Any product should be backward compatible, i.e it should not affect the older versions.. In this particular case all the older programs need to be re compiled.. I think this is a defect what ever may be the reason behind it...

Regarding ClassFormatError. Basically Stanley feels that if an applet has been compiled with 1.1 vintage JDK, it should be re-compiled with a 1.2 vintage. The backwards compatability story is unknown. In order to do a good job of understanding the compatability issues, we're going to need machines with old versions of Netscape and Java. Can someone help with this? This is from the OJI minutes at: http://www.mozilla.org/oji/status/oji-11-28- 00.txt

Direct calls from Java to the JSObject getMember and setMember methods fail due to an uninitialized JSContext. (See bugs 59447,60018). Some cases can be worked around by writing a accessor function in JavaScript and calling it using the method JSObject.call().

A change to the security model. Pre-mozilla, the browser (including JavaScript) and Java shared the same security manager. In mozilla there are two distinct and to some degree incompatible security managers. In order to make Liveconnect secure, a rather conservative security model has been implemented for calls between JavaScript and Java. This security policy is written down at: http://java.sun.com/j2se/1.3.0_01/docs/security.html#liveconnect One of the more egregious short comings its inability to compare signatures. This same origin check can only verify unsigned code sources (i.e. codebase + signature). A signed page or applet will always cause the comparison to fail.

Calling AppletContext.getDocumentBase() will return a URL without the actual HTML page name. This is different from previous version of the Netscape browser.

On 17 April 12:49:33, Stanley Man-Kit Ho wrote: > 1) JSObject.call is not working > 2) JSObject.eval is not working > 3) JSObject may not work if no JavaScript on the page >

For LiveConnect, Object tag and Embed tag are not working. Applet tag seems OK.

If I visit a page with an applet, THEN open the java console it works. Beard, what can you tell me with that information?

Presumably your diagnosis from bug #76677 explains this problem?

From bug 92024: defineClass0 problems. http://www.theintraclinic.com/locmoztest/ | http://www.robobombo.com/game.htm 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.

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

From Sergei Lunegov in bug 88501. I think this is not a bug. I tried to load this applet on Linux and Solaris (092 and 093 branches) and I used java plugin of jdk1.3.1. In java console I got the following exception: java.lang.ClassFormatError: dk/bec/webbank/clientDS/VIStack (Illegal Field name "?") at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:486) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:111) at java.net.URLClassLoader.defineClass(URLClassLoader.java:248) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:128) at sun.plugin.security.PluginClassLoader.findClass (PluginClassLoader.java:252) at java.lang.ClassLoader.loadClass(ClassLoader.java:297) at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:108) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at dk.bec.webbank.clientDS.ViewController.<init> (dk/bec/webbank/clientDS/ViewController) at dk.bec.webbank.clientDS.Main.init(dk/bec/webbank/clientDS/Main) at sun.applet.AppletPanel.run(AppletPanel.java:344) at sun.plugin.navig.motif.MotifAppletViewer.maf_run (MotifAppletViewer.java:127) at sun.plugin.navig.motif.MotifAppletViewer.run (MotifAppletViewer.java:123) at java.lang.Thread.run(Thread.java:484) I ran aplletviewer (jdk1.3.1) with flag -J-verify and got the same exception. It may means that byte code is not completely compatible to java standards. Then I ran appletviewer without any flags and I got the following exception: java.lang.NoClassDefFoundError: netscape/security/ForbiddenTargetException at dk.bec.webbank.clientDS.ViewController.<init> (dk/bec/webbank/clientDS/ViewController) at dk.bec.webbank.clientDS.Main.init(dk/bec/webbank/clientDS/Main) at sun.applet.AppletPanel.run(AppletPanel.java:344) at java.lang.Thread.run(Thread.java:484) I downloaded applet archive and decompiled some sources and class dk.bec.webbank.clientDS.Main class imports netscape.security.ForbiddenTargetException. It means that apllet has been developed for running in Netscape internal java and couldn't be used in other JREs. I think that is not Mozilla bug because: 1) I couldn't run this applet by appletviewer and saw the same exception as Mozilla throws 2) apllet has been developed using not only public API I propose to close this bug as not a bug

From bug 93730: According to the excellent analysis work of Vladimir Strigun we have reason to believe that this applet uses the method String.hashCode(). This method is not binary compatible between JDK1.1.x and Java 2 series VMs. Thus the applet needs to be recomiled. Marking INVALID.

Ressign to Joe Chou, as I am no longer working officially on OJI.

Changed priority from 3 to 4 and milestone to future.

Chris Petersen is a new QA contact for oji component. His email is: petersen@netscape.com

fixing small error for pmac@netscape.com (filter with : SPAMMAILSUCKS)

reassign to me

->kyle

Migrating plugins from NS4 to NS6 is not relevant any more. Closing this...