Closed Bug 62025 Opened 24 years ago Closed 15 years ago

Applets: What's Changed, What's Broken

Categories

(Core Graveyard :: Java: OJI, defect, P4)

Product:
Core Graveyard
Component:
Java: OJI
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: jeff.dyer, Unassigned)

Details

(Whiteboard: [oji_working]) 

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Whiteboard: [oji_working]
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)
QA Contact: shrir → pmac
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.
Assignee: edburns → joe.chou
Status: ASSIGNED → NEW
Target Milestone: --- → mozilla0.9.6
Changed priority from 3 to 4 and milestone to future.
Priority: P3 → P4
Target Milestone: mozilla0.9.6 → Future
Chris Petersen is a new QA contact for oji component. His email is:
petersen@netscape.com
Assignee: joe.chou → petersen
fixing small error for pmac@netscape.com (filter with : SPAMMAILSUCKS)
Assignee: petersen → joe.chou
QA Contact: pmac → petersen
reassign to me
Assignee: joe.chou → joshua.xia
Status: NEW → ASSIGNED
->kyle
Assignee: joshua.xia → kyle.yuan
Status: ASSIGNED → NEW
Assignee: kyle.yuan → nobody
Migrating plugins from NS4 to NS6 is not relevant any more. Closing this...
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.