13415 - Rhino: overloaded constructors

Status: RESOLVED INACTIVE

(Rhino Graveyard :: Core, defect, P5)

Description

[Norris Boyd]

Subject:
        Rhino and overloaded constructors
   Date:
        Wed, 08 Sep 1999 15:05:49 -0400
   From:
        Andrew Wason <[e-mail]>
     To:
        [e-mail]
    CC:
        Howard Lin <[e-mail]>




I'm getting this Rhino error:

js: Cannot convert [object Object] to interface java.awt.LayoutManager

 From this script:

importPackage(Packages.javax.swing);
var foo = new JPanel() {
};

One of JPanels constructors takes a LayoutManager which must be confusing
Rhinos reflection somehow.

Andrew
--
Andrew Wason
SoftCom, Inc.
[e-mail]



   bug2.js

          Name:
                bug2.js
          Type:
                Plain Text (text/plain)

Comment 1

[Norris Boyd]

Attachment bug2.js is:

importPackage(Packages.javax.swing);

var foo = new JPanel() {
};

Comment 2

[rogerl (gone)]

Need a way to convert the JS this to it's JavaAdapter this

*** This bug has been marked as a duplicate of 13417 ***

Comment 3

[Norris Boyd]

Subject:
        Re: Rhino and overloaded constructors
   Date:
        Thu, 28 Oct 1999 17:10:21 -0400
   From:
        Andrew Wason <[e-mail]>
     To:
        [e-mail]
    CC:
        Howard Lin <[e-mail]>




This was filed in Bugzilla as bugid 13415.  It is marked as a duplicate of
13417 which was fixed.

I don't see how the fix for 13417 helps with 13415.  What do I do to get
this script to work:

importPackage(Packages.javax.swing);
var foo = new JPanel() {
};

Thanks,
Andrew

Comment 4

[Norris Boyd]

The following works:

var foo = new JavaAdapter(Packages.javax.swing.JPanel, {});

Patrick, the syntax "new Packages.x() { ... }" doesn't work in this case, since
it converts to "new Packages.x({ ... })". This won't work for Java classes. What
do you think of just removing this experimental syntax and just using the syntax
"new Packages.intf({ ... })" for interfaces and "new JavaAdapter(Packages.clazz,
{...})" for classes?

Comment 5

[rogerl (gone)]

Bouncing to Patrick for an answer to Norris' question.

Comment 6

[Patrick C. Beard]

Roger and I spoke, and I explained the code as it currently stands. I'd like to 
see this syntax preserved, and perhaps a new form of NativeJavaClass.construct() 
be created, that gets called when the "new Packages.x() { ... }" form is 
encounter. Roger said that this can be done, but we should discuss further the 
right way to make this happen.

Comment 7

[Patrick C. Beard]

Reassigning back to roger.

Comment 8

[Brian D. Carlstrom]

Is this related? This worked fine in 1.4R3, I was trying to upgrade to 1.5R1

Wed Jul 19 16:33:19 PDT 2000 (T7) (script:error:2601): The choice of Java 
constructor bdc.common.core.ApprovalRequest matching JavaScript argument types 
(bdc.procure.core.Receipt,null,bdc.common.core.User,string,boolean) is 
ambiguous; candidate constructors are: 
(bdc.common.core.Approvable,bdc.common.core.Role,boolean,java.lang.String,java.l
ang.String), 
(bdc.common.core.Approvable,bdc.common.core.User,bdc.common.core.Role,java.lang.
String,boolean)

0=bdc.procure.core.Receipt
1=null
2=bdc.common.core.User
3=string
4=boolean

0=bdc.common.core.Approvable
1=bdc.common.core.Role
2=boolean
3=java.lang.String
4=java.lang.String

0=bdc.common.core.Approvable
1=bdc.common.core.User
2=bdc.common.core.Role
3=java.lang.String
4=boolean

Comment 9

[Brian D. Carlstrom]

Sorry, for the short post. What I meant to say is that it seems that if was 
called with 

0=bdc.procure.core.Receipt
1=null
2=bdc.common.core.User
3=string
4=boolean

it clearly can't be calling

0=bdc.common.core.Approvable
1=bdc.common.core.Role
2=boolean
3=java.lang.String
4=java.lang.String

because arg 2 doesn't match.

0=bdc.common.core.Approvable
1=bdc.common.core.User
2=bdc.common.core.Role
3=java.lang.String
4=boolean

does work because Receipt subclasses Approvable and User subclasses Role

Comment 10

[Dawn Endico]

cbegle is no longer @netscape.com. reassigning qa contact

Comment 11

[Travis Chase]

why is this a won't fix?

Comment 12

[Travis Chase]

Re-Opening, no reason given for being a Won't fix

Comment 13

[Igor Bukanov]

*** Bug 305907 has been marked as a duplicate of this bug. ***

Comment 14

[Norris Boyd]

Changing priority to P5 based on recent bug triage.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Closing. Bug management is now done here:
https://github.com/mozilla/rhino