Thanks for the clarification, Attila. Should I submit a bug or is this a known issue?
Mike On Wed, Sep 3, 2014 at 11:26 AM, Attila Szegedi <[email protected]> wrote: > The intended behavior is to treat Java objects as if they were JS objects > that had Object.seal() invoked on them (object is not extensible, its > existing properties are non-configurable). Therefore, attempted assignment > to a non-existent property in strict mode should fail with a TypeError, and > in non-strict mode should silently do nothing. I consider this to be a bug > in our implementation (that we aren't throwing TypeError in strict mode > when attempting assignment to a non-existent property). However, getting > the value of a non-existent property would still return undefined, as per < > http://es5.github.io/#x8.12.3>. > > Attila. > > On Sep 3, 2014, at 5:55 PM, Mike Rettig <[email protected]> wrote: > > > How about this example which demonstrates the inconsistent behavior of js > > objects versus java objects? > > > > ScriptEngineManager engineManager = > > new ScriptEngineManager(); > > final ScriptEngine nashorn = > > engineManager.getEngineByName("nashorn"); > > nashorn.eval("'use sctrict'"); > > nashorn.eval("var jsD={}"); > > nashorn.eval("jsD.badProp=1233"); > > nashorn.eval("print(jsD.badProp)"); > > > > nashorn.eval("var d= new java.util.Date()"); > > nashorn.eval("d.badProp=4567"); > > nashorn.eval("print(d.badProp)"); > > > > > > This prints: > > > > 1233 > > undefined > > > > For the java object, the assignment is allowed to the invalid field, but > > retrieving that value returns 'undefined'. This is inconsistent with > > javascript objects AND java objects. > > > > Is the intended behavior for nashorn to treat java objects like js > objects > > or like POJO's? > > > > Mike > > > > > > > > On Wed, Sep 3, 2014 at 10:32 AM, Bullotta, Rick < > [email protected] > >> wrote: > > > >> One could make the case that the Rhino behavior was actually the > incorrect > >> behavior. A missing property in JavaScript is, by definition, > undefined... > >> > >> -----Original Message----- > >> From: nashorn-dev [mailto:[email protected]] On > Behalf > >> Of Mike Rettig > >> Sent: Wednesday, September 03, 2014 11:30 AM > >> To: Hannes Wallnoefer > >> Cc: [email protected] > >> 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? > >> > >> Thanks, > >> > >> Mike > >> > >> > >> > >> > >> On Wed, Sep 3, 2014 at 10:00 AM, Hannes Wallnoefer < > >> [email protected]> 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: > >>>> sun.org.mozilla.javascript.internal.EvaluatorException: Java class > >>>> "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 > >>>> > >>> > >>> > >> > >
