If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[PATCH] importPackage Ambiguous import error fix

RESOLVED FIXED in 1.6R6

Status

Rhino
Core
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: Leszek Gawron, Unassigned)

Tracking

other
1.6R6
x86
Windows XP

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Rhino 1.6R2 (R3 also)

Originally reported at: 
http://groups.google.com/group/netscape.public.mozilla.jseng/browse_frm/thread/9551fca1f6200746/4c8cf0604bcd79ca?lnk=gst&q=ambiguous+import&rnum=1#4c8cf0604bcd79ca

quote:

Attached is a patch to fix importPackage to not import the
same package more than once.  This fixes an error that
shows up if a call to importPackage is encountered twice
before classes from the package actually get referenced.

I encountered this error while working with a flowscript
(Cocoon's name for javascript+continuations) for a set of
Cocoon forms.  Quickly starting more than one instance of
a form triggers this bug.

The patch replaces a comparison using '=' between two
NativeJavaPackage's with a comparison using string equality.
This effectively compares the package names instead of
checking for object identity.

The other thing which we might need to check is that the
two NativeJavaPackage's both use the same classloader.
I would appreciate it if somebody more knowledgeable of
Rhino internals could sanity check this patch. 


Reproducible: Couldn't Reproduce
(Reporter)

Comment 1

11 years ago
Created attachment 235905 [details] [diff] [review]
patch file

this is the original patch posted by Tim Larson on 2005-03-22 to jseng news list. It is truly a one liner.

Comment 2

11 years ago
Created attachment 241937 [details] [diff] [review]
patch using equals() on NativeJavaPackage

Actually, this is a bit problematic, as you can have a border case where the two NativeJavaPackage objects are for the same package but loaded through different class loaders. The real solution is to implement equals() and hashCode() on the NativeJavaPackage so that it compares both the name and the class loader, see attached patch -- comments welcome.
Attachment #235905 - Attachment is obsolete: true

Comment 3

11 years ago
Committed patch to CVS HEAD
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 4

11 years ago
Adding target milestone of 1.6R6 based on the date this bug was resolved FIXED.
Target Milestone: --- → 1.6R6
You need to log in before you can comment on or make changes to this bug.