Inconsistent missing property handling with java objects
mike.rettig at gmail.com
Wed Sep 3 15:55:37 UTC 2014
How about this example which demonstrates the inconsistent behavior of js
objects versus java objects?
ScriptEngineManager engineManager =
final ScriptEngine nashorn =
nashorn.eval("var d= new java.util.Date()");
For the java object, the assignment is allowed to the invalid field, but
retrieving that value returns 'undefined'. This is inconsistent with
Is the intended behavior for nashorn to treat java objects like js objects
or like POJO's?
On Wed, Sep 3, 2014 at 10:32 AM, Bullotta, Rick <rick.bullotta at thingworx.com
> One could make the case that the Rhino behavior was actually the incorrect
> -----Original Message-----
> From: nashorn-dev [mailto:nashorn-dev-bounces at openjdk.java.net] On Behalf
> Of Mike Rettig
> Sent: Wednesday, September 03, 2014 11:30 AM
> To: Hannes Wallnoefer
> Cc: nashorn-dev at openjdk.java.net
> Subject: Re: Inconsistent missing property handling with java objects
> There are a couple reasons why it is problematic for me. The java objects
> are not dynamic objects. The interface is static. Allowing silent failures
> leads to all sorts of time consuming and frustrating bugs. Nashorn doesn't
> wrap the java objects, so it should treat them like java objects.
> Referencing an unknown property on a java object should fail (as it did in
> Rhino). The current behavior is the worst of both worlds. The java object
> is not wrapped so there are no extension points (e.g. __noSuchProperty___),
> but in the case of a missing property it behaves like a js object by
> silently failing.
> Anyone know the reasoning behind this design decision?
> On Wed, Sep 3, 2014 at 10:00 AM, Hannes Wallnoefer <
> hannes.wallnoefer at oracle.com> wrote:
> > Hi Mike,
> > It was just a design decision to handle missing Java properties this
> > way in Nashorn.
> > The behaviour is implemented in NashornBottomLinker.linkBean method.
> > Unfortunately there's currently no way to configure Nashorn to behave
> > the way you want it to.
> > Regards,
> > Hannes
> > Am 2014-09-03 um 16:13 schrieb Mike Rettig:
> > With nashorn, it seems that the assignment and accessing of missing
> >> properties on java objects is handled as 'undefined'.
> >> Example:
> >> String engine = "nashorn";
> >> ScriptEngineManager engineManager =
> >> new ScriptEngineManager();
> >> final ScriptEngine nashorn = engineManager.getEngineByName(
> >> engine);
> >> nashorn.eval("var d=new java.util.Date();");
> >> nashorn.eval("d.badProp=1233");
> >> nashorn.eval("print(d.badProp)");
> >> This will print 'undefined'. It doesn't fail on the 'badProp' on the
> >> Date object. With Rhino, this would fail on the assignment of the bad
> >> property with the following error:
> >> "Exception in thread "main" javax.script.ScriptException:
> >> "java.util.Date" has no public instance field or method named "badProp".
> >> (<Unknown source>#1) in <Unknown source> at line number 1"
> >> I want the script to fail when the bad property is referenced. I've
> >> tried 'use strict', the rhino compatibility script, and attempting to
> >> define __noSuchProperty__ on the java object. I can create a wrapper
> >> object that simply delegates to the java object and throws if a
> >> property is undefined, but that seems excessive.
> >> Is this the correct behavior? Is there a way to work around this
> >> behavior in nashorn?
> >> Thanks,
> >> Mike
More information about the nashorn-dev