Re: Bug report: instanceof incompatible with mozilla_compat's importClass

Hm, would there be any bad consequences to calling load('nashorn:mozilla_compat.js') twice? On 10/10/2013 01:08 PM, A. Sundararajan wrote: I hope you call load('nashorn:mozilla_compat.js') as a top-level expression -- and not within a function. Because mozilla_compat.js assumes it is being eva

Re: Bug report: instanceof incompatible with mozilla_compat's importClass

I hope you call load('nashorn:mozilla_compat.js') as a top-level expression -- and not within a function. Because mozilla_compat.js assumes it is being evaluated with 'this' as global scope. ReferenceError may be from importPackage -- because importPackage is the one that installs __noSuchProp

Re: Bug report: instanceof incompatible with mozilla_compat's importClass

Hm, something very strange is happening, because I'm also unable to isolate this exception. Moreover, the exception is coming from importPackage in mozilla_compat, not importClass. However, nowhere am I calling importPackage. Do you have any idea what could be causing this oddity? On 10/10/2

Re: Bug report: instanceof incompatible with mozilla_compat's importClass

var x = {} load('nashorn:mozilla_compat.js') importClass(java.io.File) print(x instanceof File) var y = new File("foo"); print(y instanceof File) works fine for me. Tried with latest nashorn tip: changeset: 596:03a68e7ca1d5 tag: tip user:lagergren d

Review request for 8026167: Class cache/reuse of 'eval' scripts results in ClassCastException in some cases.

Please review http://cr.openjdk.java.net/~sundar/8026167/ -Sundar

Bug report: instanceof incompatible with mozilla_compat's importClass

Example: importClass(java.io.File) x instanceof File Will throw an exception: nashorn:mozilla_compat.js:65:20 ReferenceError: File is not defined at jdk.nashorn.internal.scripts.Script$\=nashorn\!mozilla_compat._L47$_L51(nashorn:mozilla_compat.js:65) However, this works: x instanceof ja

Nashorn works in real life

After reporting various bugs and complaints on the list, I have some good news for a change. :) The complete Prudence stack, which includes a *lot* of JavaScript code developed for years to work in Rhino, now runs perfectly fine on Nashorn. (The exact same code base also works in Rhino.) Pru

Re: hg: nashorn/jdk8/nashorn: 8026137: Fix Issues with Binary Evaluation Order

Quick question for this change set: Why does CodeGenerator#safeLiteral(...) need to test for literal nodes instead of using type information? When the right-hand-side is a primitive type, side effects cannot occur, so the additional swap/dup/pop instructions can be omitted safely. For exampl

hg: nashorn/jdk8/nashorn: 8026137: Fix Issues with Binary Evaluation Order

Changeset: 03a68e7ca1d5 Author:lagergren Date: 2013-10-09 17:53 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/03a68e7ca1d5 8026137: Fix Issues with Binary Evaluation Order Reviewed-by: hannesw, jlaskey Contributed-by: marcus.lagerg...@oracle.com, attila.szeg...@orac

Re: Bug report: can't call static methods on a Java class instance

Again, I do understand your conviction, but "sloppy" (or "simple"?) is exactly what most dynamic languages are all about. If a programmer wanted to use Java, they would. But when working in JavaScript, expectations are quite different. Unfortunately, in my opinion, Nashorn right now requires Ja

Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays

You'll also need to sign and send us an Oracle Contributor Agreement: On Oct 9, 2013, at 4:28 PM, Jim Laskey wrote: > If you can get the changes to me by Tuesday Oct 15th, I'll take a look. No > guarantees, but if the changes are small, are c

Re: Bug report: can't call static methods on a Java class instance

On Oct 9, 2013, at 4:58 PM, Tal Liron wrote: > I understand the workaround, but again I fail to see the rationale behind > Nashorn's overly-strict interface to Java. What's wrong with supporting the > shorthand in Nashorn, especially when Rhino behaves as JavaScript programmers > would expec

Re: Bug report: can't overcome Java method ambiguity in some clear cases

Fair enough. If someone writes "1.0", it's reasonable to expect they had a floating point in mind. We are probably prematurely "optimizing" the constant 1.0 to an int. I opened to track this. Attila. On Oct 9, 2013, at 4:43 PM, Andreas Woess

Re: Bug report: can't call static methods on a Java class instance

I understand the workaround, but again I fail to see the rationale behind Nashorn's overly-strict interface to Java. What's wrong with supporting the shorthand in Nashorn, especially when Rhino behaves as JavaScript programmers would expect? On 10/09/2013 10:55 PM, Attila Szegedi wrote: Yup.

Re: Bug report: can't call static methods on a Java class instance

Yup. Static methods can't be invoked on instances. This is by design. The following will work: Java.type("MyClass").myMethod() of course, you can reuse it as: var MyClass = Java.type("MyClass") ... MyClass.myMethod() As a matter of fact, you can even get the met

Re: Bug report: can't overcome Java method ambiguity in some clear cases

I see your point, but once again I'm very worried about: 1) How much Nashorn diverges from not only Rhino, but also many other JVM languages. 2) How much Nashorn diverges, in my humble opinion, from the spirit of dynamic languages, which generally prefer to plough through ambiguities rather th

Re: Bug report: can't overcome Java method ambiguity in some clear cases

Well, as I stare at it, I think this should be ambiguous. Based on JS conversion rules, both methods are applicable, and neither method is more specific than the other. I'd say this worked incidentally in Rhino, because it probably just picked the first signature that matched. Just convert your

Re: Bug report: can't overcome Java method ambiguity in some clear cases

I'd like to add to this bug report: jjs> new java.awt.Color(0.5,0.5,0.5) java.awt.Color[r=128,g=128,b=128] jjs> new java.awt.Color(1.0,0.5,0.5) java.lang.RuntimeException: java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(float, float, float), (int, int,

Bug Report: importClass in mozilla_compat.js only supports a single arguments

In Rhino this works: importClass(java.util.LinkedList, java.util.HashMap) But Nashorn will only import the first class.

Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays

If you can get the changes to me by Tuesday Oct 15th, I'll take a look. No guarantees, but if the changes are small, are correct, and do not restrict future enhancements in this area then I'll run the changes up the approval chain. Cheers, -- Jim - Original Message - From: tal.li...@

Bug report: can't overcome Java method ambiguity in some clear cases

Here's a particular exception I got: java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(java.lang.String, java.lang.String), (int, java.lang.Object)] of the method org.restlet.util.Series.set for argument types [java.lang.String, java.lang.Integer]

Bug report: can't call static methods on a Java class instance

If we have a Java class: class MyClass { public static void myMethod(); } And in JavaScript try: myInstance.myMethod() Then we would get an exception that looks something like this: myscript.js:... TypeError: MyClass@... has no such function "myMethod" at jdk.nashorn.internal.runtime.EC

Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays

I deem this feature important for Nashorn's adoption: if I could submit a patch soon, would it be possible to make it in time for release? On 10/09/2013 04:15 PM, Jim Laskey (Oracle) wrote: After consideration and from my own experiences, I'm going to add as a feature request. However, code fr

Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays

Thank you for this, it's still a bit hard to follow but I will give it a try. I should state that I entirely agree with you regarding the ambiguity of coercion, but I think the problem is minimized when you document the limitations. You can't support everything--by definition--but you can all

Re: Bug report: NPE in DebugLogger.levelAbove

Not in this case. But in any case, Logger.getLevel may very well return null by its implementation and documentation. On 10/09/2013 03:53 PM, Jim Laskey (Oracle) wrote: Are you multi-threading? On 2013-10-09, at 8:43 AM, Tal Liron wrote: The code uses Logger.getLevel(), but doesn't take in

hg: nashorn/jdk8/nashorn: 8026008: Constant folding removes var statement

Changeset: ec3094d9d5d5 Author:hannesw Date: 2013-10-09 14:50 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/ec3094d9d5d5 8026008: Constant folding removes var statement Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/FoldConstants.java + test/script

hg: nashorn/jdk8/nashorn: 8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be cast to jdk.nashorn.internal.

Changeset: 1e03d7caa68b Author:sundar Date: 2013-10-09 13:26 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/1e03d7caa68b 8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be

Re: Review request for 8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be cast to jdk.nashorn.internal.run

+1 Am 2013-10-09 12:15, schrieb A. Sundararajan: Please review http://cr.openjdk.java.net/~sundar/8026125/ -Sundar

Review request for 8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be cast to jdk.nashorn.internal.runtime

Please review http://cr.openjdk.java.net/~sundar/8026125/ -Sundar

Re: Review request for JDK-8026008: Constant folding removes var statement

+1 On Wednesday 09 October 2013 10:47 AM, Hannes Wallnoefer wrote: Please review JDK-8026008: Constant folding removes var statement: http://cr.openjdk.java.net/~hannesw/8026008/ Thanks, Hannes

Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays

Well, the API of GuardingTypeConverterFactory should be fairly straightforward: you're asked for a conversion from a type to a type, you're supposed to return a conditional invocation (invocation with a guard). What you'd do is react to any calls where to.isArray() == false with null, and to.isA

hg: nashorn/jdk8/nashorn: 8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object

Changeset: 8d29733ad609 Author:sundar Date: 2013-10-09 10:47 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/8d29733ad609 8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object Reviewed-by: lagergren

Re: Review request for 8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object

Looks good to me. Hannes Am 2013-10-09 10:34, schrieb A. Sundararajan: Please review http://cr.openjdk.java.net/~sundar/8026112/ -Sundar

Review request for JDK-8026008: Constant folding removes var statement

Please review JDK-8026008: Constant folding removes var statement: http://cr.openjdk.java.net/~hannesw/8026008/ Thanks, Hannes

Review request for 8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object

Please review http://cr.openjdk.java.net/~sundar/8026112/ -Sundar

Re: Bug report: JavaScript arrays are not coerced into Java arrays when calling Java functions that expect arrays

After consideration and from my own experiences, I'm going to add as a feature request. However, code freeze is next week, so it's extremely likely this will not show up until first non-security update. JDK-8026113 Cheers, -- Jim On 2013-10-08, at 9:02 PM, Tal Liron wrote: > Until he f

Re: Bug report: NPE in DebugLogger.levelAbove

Are you multi-threading? On 2013-10-09, at 8:43 AM, Tal Liron wrote: > The code uses Logger.getLevel(), but doesn't take into account that the value > could be null. Exception trace: > > java.lang.NullPointerException >at > jdk.nashorn.internal.runtime.DebugLogger.levelAbove(DebugLogger.