date:20151209

Re: 8144979: Context.fromClass should catch exception from Class.getClassLoader call

2015-12-09 Thread Sundararajan Athijegannathan

This is in response to 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005699.html


Found the root cause of difference in behavior between "jake/jigsaw" and 
"jdk9-dev".

Filed: https://bugs.openjdk.java.net/browse/JDK-8145070

Thanks,
-Sundar

Re: Nashorn webview issue

2015-12-09 Thread Sundararajan Athijegannathan

Are you using any JSAdapter over netscape.javascript.JSObject instances? 
If so, that is no longer needed! Nashorn natively supports Browser 
JSObjects - you can access properties/functions from JSObjects directly. 
Also you can pass nashorn functions (or assign callbacks). See for 
example: 
http://hg.openjdk.java.net/jdk9/dev/nashorn/file/c779bd47d648/samples/browser_dom.js


-Sundar

On 12/9/2015 6:10 PM, Jim Laskey (Oracle) wrote:

Which version of jjs are you using? (jjs -version)

— Jim



On Dec 1, 2015, at 1:11 AM, Chris Root  wrote:

I'm trying to get two way communication working for a browser project in
Nashorn and I'm having trouble implementing an HTML to host callback. I
tried this in Java using setMember and it works perfectly, but I can't seem
to duplicate it with Nashorn. Since using setMember didn't work I decided
to use the approach below but still no luck.

I don't want to pick up objects from the window object, I want to plant a
function in window that will call Nashorn code. Again getting this to work
in Java was no problem. I followed the instructions on this page

https://blogs.oracle.com/nashorn/entry/porting_from_the_browser_to

I have the jsObject wrapper shown in the article and it works fine. but the
code below doesn't work. This is the relevant snip from the load handler.

This.engine.loadWorker.stateProperty().addListener(new ChangeListener() {
changed: function(value, oldState, newState) {
  switch(newState){
case Worker.State.SUCCEEDED:
  This.document = wrap(This.engine.executeScript("document"));
  This.window = wrap(This.engine.executeScript("window"));
  This.window.hello = function(){
This.hello();
  }

As you can see I planted a function on the window called hello, which calls
a method of the webview wrapper (same wrapper as in the article) called
hello()

This.hello = function(){
  print("** hello it worked ***");
}

I then set up the alert handler

This.engine.onAlert = new javafx.event.EventHandler() {
  handle: function(evt) {
print(evt.data)
  }
};

and then finally loaded the HTML file below into the webview.



  Nashorn Browser

  
function sayhello(){
  try{
hello();
  }catch(e){
alert(e.message)
  }
}
  



  Say Hello



What I get back in the console is.

JavaRuntimeObject is not a function (evaluating 'window.hello()')

Is there any way to establish a callback into my Nashorn code the way it
can be done in Java?

Re: Nashorn webview issue

2015-12-09 Thread Jim Laskey (Oracle)

Which version of jjs are you using? (jjs -version)

— Jim


> On Dec 1, 2015, at 1:11 AM, Chris Root  wrote:
> 
> I'm trying to get two way communication working for a browser project in
> Nashorn and I'm having trouble implementing an HTML to host callback. I
> tried this in Java using setMember and it works perfectly, but I can't seem
> to duplicate it with Nashorn. Since using setMember didn't work I decided
> to use the approach below but still no luck.
> 
> I don't want to pick up objects from the window object, I want to plant a
> function in window that will call Nashorn code. Again getting this to work
> in Java was no problem. I followed the instructions on this page
> 
> https://blogs.oracle.com/nashorn/entry/porting_from_the_browser_to
> 
> I have the jsObject wrapper shown in the article and it works fine. but the
> code below doesn't work. This is the relevant snip from the load handler.
> 
> This.engine.loadWorker.stateProperty().addListener(new ChangeListener() {
>changed: function(value, oldState, newState) {
>  switch(newState){
>case Worker.State.SUCCEEDED:
>  This.document = wrap(This.engine.executeScript("document"));
>  This.window = wrap(This.engine.executeScript("window"));
>  This.window.hello = function(){
>This.hello();
>  }
> 
> As you can see I planted a function on the window called hello, which calls
> a method of the webview wrapper (same wrapper as in the article) called
> hello()
> 
> This.hello = function(){
>  print("** hello it worked ***");
> }
> 
> I then set up the alert handler
> 
> This.engine.onAlert = new javafx.event.EventHandler() {
>  handle: function(evt) {
>print(evt.data)
>  }
> };
> 
> and then finally loaded the HTML file below into the webview.
> 
> 
> 
>  Nashorn Browser
> 
>  
>function sayhello(){
>  try{
>hello();
>  }catch(e){
>alert(e.message)
>  }
>}
>  
> 
> 
> 
>  Say Hello
> 
> 
> 
> What I get back in the console is.
> 
> JavaRuntimeObject is not a function (evaluating 'window.hello()')
> 
> Is there any way to establish a callback into my Nashorn code the way it
> can be done in Java?

Re: 8144979: Context.fromClass should catch exception from Class.getClassLoader call

2015-12-09 Thread Attila Szegedi

Thanks for the response; basically we don't have an understanding about the 
cause of the exception in the modular world then. I wonder if we could bother 
Jigsaw folks with this. They do seem to be quite busy on the mailing lists 
these days :-)

+1 on the change - it's not harmful by any means and makes the code more 
robust. As you said, dereferencing the class loader is just an optimization.

Attila.

> On Dec 9, 2015, at 10:50 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Hi,
> 
> Inline comments below...
> 
> 
> On 12/9/2015 2:08 PM, Attila Szegedi wrote:
>> So… I presume the security exception only thrown when a SecurityManager is
>> present?
> 
> Yes. But note that we run all the tests under a security manager (except for 
> tests under "test/script/nosecurity" directory)
> 
>> This is actually somewhat weird, especially since VM anonymous
>> classes should return their host class' loader as their loader.
>> getClassLoader() doc says
>> 
>> If a security manager is present, and the caller's class loader is not null
> 
> Well, for unknown reason,  this fails in jake/nashorn - but not on 
> jdk9-dev/nashorn. I'm trying to come up with a standalone test to reproduce 
> it - but not
> successful so far.
>>> and the caller's class loader is not the same as or an ancestor of the
>>> class loader for the class whose class loader is requested, then this
>>> method calls the security manager's checkPermission method with a
>>> RuntimePermission("getClassLoader") permission
>> 
>> I'd think that for Context.class.classLoader it is true that it is either
>> null or the ancestor of the script's class loader, is that not so?
> 
> Nashorn's loader is extension loader. And it is ancestor of script loader. 
> because script loader uses thread context loader as parent - and thread 
> context loader's parent is extension loader in this case.
> 
> 
>> I'm just
>> trying to understand *why* can this SecurityException arise at all.
> 
> As I said, tests are run under security manager and tests do fail in 
> jake/nashorn without this change. As for the root cause, I/we need to 
> understand by coming up with an independent test case (yet).
> This workaround fix is for two reasons:
> 
> 1) Will make future jdk9-> jake merge would be clean (for this file/method)
> 2) When jake merges to jdk9 in future, we don't want failure in this part of 
> code to disrupt nashorn test run. Because this is just an optimization (to 
> get Context from loader instance). We should be able
> to get current Context from thread-local in any case. i.e., should not 
> fail/disrupt test run for this reason.
> 
> Thanks,
> -Sundar
> 
>> Attila.
>> 
>> 
>> On Wed, Dec 9, 2015 at 9:20 AM, Michael Haupt 
>> wrote:
>> 
>>> Hi Sundar,
>>> 
>>> lower-case thumbs up.
>>> 
>>> One remark: I'm a bit concerned about the plethora of files involved with
>>> the dynalink samples. For each particular sample, there's a Java file, a
>>> sample JS file, and a linker JS file, where the linker compiles the Java
>>> file and assembles a JAR. The linkers all look pretty much the same. In my
>>> opinion, providing one script that takes care of compilation and JARring
>>> and is loaded from all actual samples would keep the samples more lean.
>>> 
>>> Best,
>>> 
>>> Michael
>>> 
 Am 09.12.2015 um 08:56 schrieb Sundararajan Athijegannathan <
>>> sundararajan.athijegannat...@oracle.com>:
 Please review http://cr.openjdk.java.net/~sundar/8144979/ for
>>> https://bugs.openjdk.java.net/browse/JDK-8144979
 This fix is already in jake/nashorn. See also:
>>> https://bugs.openjdk.java.net/browse/JDK-8144568
 In addition, I've moved all dynalink samples to
>>> $nashorn/samples/dynalink directory and renamed the README.
 Thanks,
 -Sundar
>>> --
>>> 
>>>  
>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>> Oracle Java Platform Group | LangTools Team | Nashorn
>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam,
>>> Germany
>>>   Oracle is committed to developing
>>> practices and products that help protect the environment
>>> 
>>> 
>

Re: Sharing native JavaScript objects across contexts

2015-12-09 Thread Sundararajan Athijegannathan

This is in response to 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005690.html 
[ I accidentally deleted the original email ]


Yes, objects from other ScriptContexts are indeed foreign - but nashorn 
allows you to call functions, access properties and so on.And even when 
you're using multiple ScriptContexts in the same engine -- compiled 
Classes (java.lang.Class instances) are shared. i.e., so long as you use 
same script, Nashorn will re-use Class objects.
i.e., compiled code sharing is on per-engine basis. So, you can eval 
"common code" again and again -- you'll be re-using same Class object.


You don't share ECMAScript global objects (which are in ENGINE_SCOPE of 
the ScriptContexts you use) -- but that is only about objects including 
function objects. But you still share nashorn compiled code -- so long 
as you use the same script engine instance.


Hope that answers your concerns,
-Sundar

Re: Keeping ScriptEngine per Thread?

2015-12-09 Thread Frantzius , Jörg

Hi Sundar,

thanks for your answer. So that seems to mean that ScriptEngine per se is 
thread-safe, and we can isolate threads by providing separate ScriptContexts. 
It’s good to know we can use a singleton ScriptEngine in case memory footprint 
turns out to be too big.

Thx + regards,
Jörg

---

Dipl. Inf. Jörg von Frantzius, Technical Director

E-Mail joerg.frantz...@aperto.com

Phone +49 30 283921-0
Fax +49 30 283921-29

Aperto AG - In der Pianofabrik
Chausseestraße 5, D-10115 Berlin
http://www.aperto.com
http://www.facebook.com/aperto
https://www.xing.com/companies/apertoag

HRB 77049 B, AG Berlin Charlottenburg
Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen, Daniel 
Simon
Aufsichtsrat: Bernd Hardes (Vorsitzender)

Am 09.12.2015 um 10:55 schrieb Sundararajan Athijegannathan 
mailto:sundararajan.athijegannat...@oracle.com>>:

One engine per worker thread would definitely work - this is maximum isolation. 
This mode even avoids sharing script classers / loaders.

If that is not workable in your use-case, you can use a separate ENGINE_SCOPE 
bindings (or separate ScriptContext) per thread. This will separate ECMAScript 
globals to be thread specific. This mode allows for script Class 
(compiled/loaded script Class objects) to be shared -- but global state is not. 
This is partial sharing - but safe.

If you do share the default ScriptContext of the script engine across threads, 
then it is up to you to take care of MT access/modification of globals -- you 
could still carefully structure code to run script functions in a such a way to 
avoid concurrent global modifications - but it'd be practically difficult.

Hope this helps,
-Sundar

On 12/9/2015 2:58 PM, Frantzius, Jörg wrote:
Hi,

we’re using Oracle JDK’s Nashorn in a web application, where it is used to 
render HTML markup in HTTP worker threads.

I remember having read somewhere that the creation of a ScriptEngine (i.e. 
invocation of ScriptEngineFactory.getScriptEngine()) may have considerable 
performance overhead, so probably it should be avoided to do this with every 
incoming HTTP request. This is why we’ll go for keeping a ScriptEngine per 
thread in a ThreadLocal.

On the other hand this may result in a large memory footprint, as there can be 
200 HTTP worker threads, but we don’t have any experience with it yet.

The ScriptEngineFactory.getParameter() 
Javadocs
 does list some interesting parameters for the key „THREADING“, that seem to 
make it possible to have a singleton ScriptEngine instead, which could be used 
concurrently from multiple threads. However, I have no clue whether this is 
either supported by Nashorn, nor how to set this parameter on engine creation.

Is there per chance some recommended usage pattern for ScriptEngine in a web 
server?

Thanks for any insights,
Jörg


---

Dipl. Inf. Jörg von Frantzius, Technical Director

E-Mail joerg.frantz...@aperto.com

Phone +49 30 283921-0
Fax +49 30 283921-29

Aperto AG - In der Pianofabrik
Chausseestraße 5, D-10115 Berlin
http://www.aperto.com
http://www.facebook.com/aperto
https://www.xing.com/companies/apertoag

HRB 77049 B, AG Berlin Charlottenburg
Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen, Daniel 
Simon
Aufsichtsrat: Bernd Hardes (Vorsitzender)

Re: Keeping ScriptEngine per Thread?

2015-12-09 Thread Sundararajan Athijegannathan

One engine per worker thread would definitely work - this is maximum 
isolation. This mode even avoids sharing script classers / loaders.


If that is not workable in your use-case, you can use a separate 
ENGINE_SCOPE bindings (or separate ScriptContext) per thread. This will 
separate ECMAScript globals to be thread specific. This mode allows for 
script Class (compiled/loaded script Class objects) to be shared -- but 
global state is not. This is partial sharing - but safe.


If you do share the default ScriptContext of the script engine across 
threads, then it is up to you to take care of MT access/modification of 
globals -- you could still carefully structure code to run script 
functions in a such a way to avoid concurrent global modifications - but 
it'd be practically difficult.


Hope this helps,
-Sundar

On 12/9/2015 2:58 PM, Frantzius, Jörg wrote:

Hi,

we’re using Oracle JDK’s Nashorn in a web application, where it is used to 
render HTML markup in HTTP worker threads.

I remember having read somewhere that the creation of a ScriptEngine (i.e. 
invocation of ScriptEngineFactory.getScriptEngine()) may have considerable 
performance overhead, so probably it should be avoided to do this with every 
incoming HTTP request. This is why we’ll go for keeping a ScriptEngine per 
thread in a ThreadLocal.

On the other hand this may result in a large memory footprint, as there can be 
200 HTTP worker threads, but we don’t have any experience with it yet.

The ScriptEngineFactory.getParameter() 
Javadocs
 does list some interesting parameters for the key „THREADING“, that seem to make it 
possible to have a singleton ScriptEngine instead, which could be used concurrently 
from multiple threads. However, I have no clue whether this is either supported by 
Nashorn, nor how to set this parameter on engine creation.

Is there per chance some recommended usage pattern for ScriptEngine in a web 
server?

Thanks for any insights,
Jörg


---

Dipl. Inf. Jörg von Frantzius, Technical Director

E-Mail joerg.frantz...@aperto.com

Phone +49 30 283921-0
Fax +49 30 283921-29

Aperto AG - In der Pianofabrik
Chausseestraße 5, D-10115 Berlin
http://www.aperto.com
http://www.facebook.com/aperto
https://www.xing.com/companies/apertoag

HRB 77049 B, AG Berlin Charlottenburg
Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen, Daniel 
Simon
Aufsichtsrat: Bernd Hardes (Vorsitzender)

Re: 8144979: Context.fromClass should catch exception from Class.getClassLoader call

2015-12-09 Thread Sundararajan Athijegannathan


Hi,

Inline comments below...


On 12/9/2015 2:08 PM, Attila Szegedi wrote:

So… I presume the security exception only thrown when a SecurityManager is
present?


Yes. But note that we run all the tests under a security manager (except 
for tests under "test/script/nosecurity" directory)



This is actually somewhat weird, especially since VM anonymous
classes should return their host class' loader as their loader.
getClassLoader() doc says

If a security manager is present, and the caller's class loader is not null


Well, for unknown reason,  this fails in jake/nashorn - but not on 
jdk9-dev/nashorn. I'm trying to come up with a standalone test to 
reproduce it - but not

successful so far.

and the caller's class loader is not the same as or an ancestor of the
class loader for the class whose class loader is requested, then this
method calls the security manager's checkPermission method with a
RuntimePermission("getClassLoader") permission


I'd think that for Context.class.classLoader it is true that it is either
null or the ancestor of the script's class loader, is that not so?


Nashorn's loader is extension loader. And it is ancestor of script 
loader. because script loader uses thread context loader as parent - and 
thread context loader's parent is extension loader in this case.




I'm just
trying to understand *why* can this SecurityException arise at all.


As I said, tests are run under security manager and tests do fail in 
jake/nashorn without this change. As for the root cause, I/we need to 
understand by coming up with an independent test case (yet).

This workaround fix is for two reasons:

1) Will make future jdk9-> jake merge would be clean (for this file/method)
2) When jake merges to jdk9 in future, we don't want failure in this 
part of code to disrupt nashorn test run. Because this is just an 
optimization (to get Context from loader instance). We should be able
to get current Context from thread-local in any case. i.e., should not 
fail/disrupt test run for this reason.


Thanks,
-Sundar


Attila.


On Wed, Dec 9, 2015 at 9:20 AM, Michael Haupt 
wrote:


Hi Sundar,

lower-case thumbs up.

One remark: I'm a bit concerned about the plethora of files involved with
the dynalink samples. For each particular sample, there's a Java file, a
sample JS file, and a linker JS file, where the linker compiles the Java
file and assembles a JAR. The linkers all look pretty much the same. In my
opinion, providing one script that takes care of compilation and JARring
and is loaded from all actual samples would keep the samples more lean.

Best,

Michael


Am 09.12.2015 um 08:56 schrieb Sundararajan Athijegannathan <

sundararajan.athijegannat...@oracle.com>:

Please review http://cr.openjdk.java.net/~sundar/8144979/ for

https://bugs.openjdk.java.net/browse/JDK-8144979

This fix is already in jake/nashorn. See also:

https://bugs.openjdk.java.net/browse/JDK-8144568

In addition, I've moved all dynalink samples to

$nashorn/samples/dynalink directory and renamed the README.

Thanks,
-Sundar

--

  
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam,
Germany
   Oracle is committed to developing
practices and products that help protect the environment

Keeping ScriptEngine per Thread?

2015-12-09 Thread Frantzius , Jörg

Hi,

we’re using Oracle JDK’s Nashorn in a web application, where it is used to 
render HTML markup in HTTP worker threads.

I remember having read somewhere that the creation of a ScriptEngine (i.e. 
invocation of ScriptEngineFactory.getScriptEngine()) may have considerable 
performance overhead, so probably it should be avoided to do this with every 
incoming HTTP request. This is why we’ll go for keeping a ScriptEngine per 
thread in a ThreadLocal.

On the other hand this may result in a large memory footprint, as there can be 
200 HTTP worker threads, but we don’t have any experience with it yet.

The ScriptEngineFactory.getParameter() 
Javadocs
 does list some interesting parameters for the key „THREADING“, that seem to 
make it possible to have a singleton ScriptEngine instead, which could be used 
concurrently from multiple threads. However, I have no clue whether this is 
either supported by Nashorn, nor how to set this parameter on engine creation.

Is there per chance some recommended usage pattern for ScriptEngine in a web 
server?

Thanks for any insights,
Jörg


---

Dipl. Inf. Jörg von Frantzius, Technical Director

E-Mail joerg.frantz...@aperto.com

Phone +49 30 283921-0
Fax +49 30 283921-29

Aperto AG - In der Pianofabrik
Chausseestraße 5, D-10115 Berlin
http://www.aperto.com
http://www.facebook.com/aperto
https://www.xing.com/companies/apertoag

HRB 77049 B, AG Berlin Charlottenburg
Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen, Daniel 
Simon
Aufsichtsrat: Bernd Hardes (Vorsitzender)

Re: 8144979: Context.fromClass should catch exception from Class.getClassLoader call

2015-12-09 Thread Attila Szegedi

So… I presume the security exception only thrown when a SecurityManager is
present? This is actually somewhat weird, especially since VM anonymous
classes should return their host class' loader as their loader.
getClassLoader() doc says

If a security manager is present, and the caller's class loader is not null
> and the caller's class loader is not the same as or an ancestor of the
> class loader for the class whose class loader is requested, then this
> method calls the security manager's checkPermission method with a
> RuntimePermission("getClassLoader") permission


I'd think that for Context.class.classLoader it is true that it is either
null or the ancestor of the script's class loader, is that not so? I'm just
trying to understand *why* can this SecurityException arise at all.

Attila.


On Wed, Dec 9, 2015 at 9:20 AM, Michael Haupt 
wrote:

> Hi Sundar,
>
> lower-case thumbs up.
>
> One remark: I'm a bit concerned about the plethora of files involved with
> the dynalink samples. For each particular sample, there's a Java file, a
> sample JS file, and a linker JS file, where the linker compiles the Java
> file and assembles a JAR. The linkers all look pretty much the same. In my
> opinion, providing one script that takes care of compilation and JARring
> and is loaded from all actual samples would keep the samples more lean.
>
> Best,
>
> Michael
>
> > Am 09.12.2015 um 08:56 schrieb Sundararajan Athijegannathan <
> sundararajan.athijegannat...@oracle.com>:
> >
> > Please review http://cr.openjdk.java.net/~sundar/8144979/ for
> https://bugs.openjdk.java.net/browse/JDK-8144979
> > This fix is already in jake/nashorn. See also:
> https://bugs.openjdk.java.net/browse/JDK-8144568
> >
> > In addition, I've moved all dynalink samples to
> $nashorn/samples/dynalink directory and renamed the README.
> >
> > Thanks,
> > -Sundar
>
> --
>
>  
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> Oracle Java Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam,
> Germany
>   Oracle is committed to developing
> practices and products that help protect the environment
>
>

Re: 8144979: Context.fromClass should catch exception from Class.getClassLoader call

2015-12-09 Thread Michael Haupt

Hi Sundar,

lower-case thumbs up.

One remark: I'm a bit concerned about the plethora of files involved with the 
dynalink samples. For each particular sample, there's a Java file, a sample JS 
file, and a linker JS file, where the linker compiles the Java file and 
assembles a JAR. The linkers all look pretty much the same. In my opinion, 
providing one script that takes care of compilation and JARring and is loaded 
from all actual samples would keep the samples more lean.

Best,

Michael

> Am 09.12.2015 um 08:56 schrieb Sundararajan Athijegannathan 
> :
> 
> Please review http://cr.openjdk.java.net/~sundar/8144979/ for 
> https://bugs.openjdk.java.net/browse/JDK-8144979
> This fix is already in jake/nashorn. See also: 
> https://bugs.openjdk.java.net/browse/JDK-8144568
> 
> In addition, I've moved all dynalink samples to $nashorn/samples/dynalink 
> directory and renamed the README.
> 
> Thanks,
> -Sundar

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
  Oracle is committed to developing 
practices and products that help protect the environment

Re: 8144979: Context.fromClass should catch exception from Class.getClassLoader call

Re: Nashorn webview issue

Re: Nashorn webview issue

Re: 8144979: Context.fromClass should catch exception from Class.getClassLoader call

Re: Sharing native JavaScript objects across contexts

Re: Keeping ScriptEngine per Thread?

Re: Keeping ScriptEngine per Thread?

Re: 8144979: Context.fromClass should catch exception from Class.getClassLoader call

Keeping ScriptEngine per Thread?

Re: 8144979: Context.fromClass should catch exception from Class.getClassLoader call

Re: 8144979: Context.fromClass should catch exception from Class.getClassLoader call

11 matches

Site Navigation

Mail list logo

Footer information