ScriptFunction being passed to JSObject, expected ScriptObjectMirror

[Sundararajan Athijegannathan]

I think you can do something like this:

import javax.script.*;
import jdk.nashorn.api.scripting.JSObject;

public class Main {
   public static void main(String[] args) throws Exception {
      ScriptEngineManager m = new ScriptEngineManager();
      ScriptEngine e = m.getEngineByName("nashorn");
      JSObject global = (JSObject) e.eval("this");
      Object undefined = global.getMember("undefined");
      System.out.println(undefined);
   }
}

Thanks,
-Sundar

On 28/08/17, 10:03 PM, Jesse Schulman wrote:
> Awesome, thanks for the quick response!
>
> On a somewhat related note, what is the proper way of returning 
> 'undefined' from a JSObject implementation?  I have seen it work 
> various ways but when I have tested our application on the jdk9 beta 
> releases I have had to take a different approach than 
> Undefined.getUndefined() or ScriptRuntime.UNDEFINED since as you 
> mention in that bug report the internal package cannot be accessed.
>
> Thanks again,
> Jesse
>
> On Sun, Aug 27, 2017 at 9:59 PM Sundararajan Athijegannathan 
> <sundararajan.athijegannathan at oracle.com 
> <mailto:sundararajan.athijegannathan at oracle.com>> wrote:
>
>     Hi,
>
>     Thanks for the standalone test case! I reproduced the issue and
>     filed a bug -> https://bugs.openjdk.java.net/browse/JDK-8186807
>
>     Thanks,
>     -Sundar
>
>
>     On 24/08/17, 11:11 PM, Jesse Schulman wrote:
>>     The type is ScriptFunction, I've created a simple reproducer that
>>     I've pushed to
>>     https://github.com/jesseschulman/JSObject_gets_ScriptFunction
>>     <https://github.com/jesseschulman/JSObject_gets_ScriptFunction.git>
>>
>>     Thanks!
>>     Jesse
>>
>>     On Thu, Aug 24, 2017 at 1:05 AM Sundararajan Athijegannathan
>>     <sundararajan.athijegannathan at oracle.com
>>     <mailto:sundararajan.athijegannathan at oracle.com>> wrote:
>>
>>         what is the type of args[0]? Can you print args[0].getClass()
>>         to check it?
>>
>>         Thanks,
>>         -Sundar
>>
>>
>>         On 24/08/17, 9:14 AM, Jesse Schulman wrote:
>>>         I did try running with -Dnashorn.apply2call=false when I saw
>>>         the email for that fix but it did not resolve the issue.
>>>
>>>         There is no exception thrown, but our JSObject.call method
>>>         basically is no-op as a result of not getting a
>>>         ScriptObjectMirror, it effectively looks like this:
>>>
>>>                 @Override
>>>                 public Object call(Object thiz, Object ... args) {
>>>                     if (args.length < 2 || !(args[0] instanceof
>>>         ScriptObjectMirror) || !((ScriptObjectMirror)
>>>         args[0]).isFunction() || !(args[1] instanceof Integer))
>>>                         return gScriptEnvironment.getUndefined();
>>>
>>>                     // safely cast and call ScriptObjectMirror...
>>>                }
>>>
>>>
>>>         I am continuing to work on reproducing it outside our
>>>         application in a simple way.  In the mean time if there's
>>>         any other information I can share besides a reproducing
>>>         example, or suggestions on workarounds to try let me know.
>>>
>>>         Thanks!
>>>         Jesse
>>>
>>>         On Wed, Aug 23, 2017 at 7:10 PM Sundararajan Athijegannathan
>>>         <sundararajan.athijegannathan at oracle.com
>>>         <mailto:sundararajan.athijegannathan at oracle.com>> wrote:
>>>
>>>             Hi,
>>>
>>>             Sorry for the delayed response. We need more info to
>>>             debug this - in
>>>             particular, what is the exception (if any) thrown etc.
>>>
>>>             I wonder if this is related to this recent apply-related
>>>             fix ->
>>>
>>>             http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-August/006998.html
>>>
>>>             -Sundar
>>>
>>>             On 22/08/17, 3:43 AM, Jesse Schulman wrote:
>>>             > This does not happen on the first run of the code but
>>>             is consistently
>>>             > happening on the 17th run after a restart and from
>>>             that point forward is
>>>             > broken until we restart.
>>>             >
>>>             > Attached is a broken and working call stack.
>>>             >
>>>             > I have tried to replicate what we are doing in a basic
>>>             java reproducer but
>>>             > have not been able to do so, given that I can
>>>             consistently reproduce this
>>>             > locally I am happy to take any suggested steps to
>>>             gather more information
>>>             > or to workaround/resolve the issue.
>>>             >
>>>             > Environment:
>>>             > Java version 1.8.144
>>>             > Engine created with "--no-java", "-strict",
>>>             "--no-syntax-extensions",
>>>             > "--language=es6", "--optimistic-types=true"  (also
>>>             tried with
>>>             > optimistic-types=false)
>>>             > All evaluation done on the same engine via
>>>             engine.eval(String, Bindings)
>>>             > using a Bindings that was returned from
>>>             engine.createBindings, each of the
>>>             > "runs" described above took place in a different
>>>             Bindings instance
>>>             >
>>>             > Thanks!
>>>             > Jesse
>>>