This is actually a great reason to support custom wrap factories/adapters, so that application specific type conversion and name resolution can be done without burdening the script developer of this type of syntax, which, to be honest, would be a bit intimidating. I certainly wouldn't want to ask someone used to writing general purpose JavaScript to have to understand which objects were Java objects and which objects were JS objects. The power can be in the abstraction. I think a focus on a clean syntax is essential if we want Nashorn to empower higher level developers to use scripting (which we have been able to readily achieve with Rhino).
Just my $0.02, before taxes. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jim Laskey (Oracle) Sent: Tuesday, October 08, 2013 8:24 AM To: Tal Liron Cc: [email protected] Subject: Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays Nashorn does not coerce JS arrays implicitly. There were too many ambiguous cases to do a complete implementation (nested conversions.) In Nashorn you have to; myInstance.myMethod(Java.to(['a', 'b', 'c'], "java.lang.String[]")); or; var StringArray = Java.type("java.lang.String[]"); function args(array) { return Java.to(array, StringArray); } myInstance.myMethod(args(['a', 'b', 'c'])); Cheers, -- Jim On 2013-10-08, at 1:54 PM, Tal Liron <[email protected]> wrote: > Lets say we have a Java class with this method: > > class MyClass { > void myMethod(String[] arguments) {} > } > > And in Nashorn we call it like so: > > myInstance.myMethod(['a', 'b', 'c']) > > The JavaScript array seems to be converted into a string (as "a,b,c"), and > then wrapped in a Java string array as its single element before sending to > Java. > > In Rhino, the above works as expected.
