Inconsistent missing property handling with java objects

[Attila Szegedi]

It wasn't known before you pointed it out - I just filed <https://bugs.openjdk.java.net/browse/JDK-8057173> to track this. This is definitely something we want to fix.

Attila.

On Sep 3, 2014, at 7:25 PM, Mike Rettig <mike.rettig at gmail.com> wrote:

> 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 <attila.szegedi at oracle.com> 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 <mike.rettig at gmail.com> 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 <rick.bullotta at thingworx.com
> >> 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: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?
> >>
> >> Thanks,
> >>
> >> Mike
> >>
> >>
> >>
> >>
> >> 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:
> >>>> 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
> >>>>
> >>>
> >>>
> >>
> 
>