Nashorn Roadmap & Rhino migration question

[A. Sundararajan]

Hi,

Nashorn engine picks up thread-context loader at the time of engine 
creation or user supplied loader (with nashorn specific extension API).

For the cases like you specify, you've to use reflection - but only to 
get to the class. Something like

// get java.lang.Class object of the desired class using the class 
loader "mediaCL"
var myClass = 
java.lang.Class.forName("customPackages.com.mycompany.MyClass", true, 
mediaCL);
// make "static" reference to that class.
// MyClass is an instance of StaticClass in nashorn
var MyClass = myClass.static;

// MyClass can be used just like you'd use other java classes from script

// new object
var obj = new MyClass();
// instance method
obj.mymethod("bar");
// static method
print(MyClass.myStaticBar());

Hope this helps,
-Sundar

On Monday 04 August 2014 05:45 PM, Paul Bakker wrote:
> Hi,
>
> Tnx for the clarifications.
>
> @sundar: I realise that I didn't properly clarify my question. What we 
> do in Rhino is load classes using a custom classloader inside 
> scripting. like this:
>     try {
>         var cx = 
> Packages.org.mozilla.javascript.Context.getCurrentContext()
>         var savedCL = cx.getApplicationClassLoader()
>         var mediaCL = java.net.URLClassLoader([new 
> java.net.URL("mycustomprotocol:///bin/")], savedCL)
>         cx.setApplicationClassLoader(mediaCL)
>         var customPackages = new Packages(mediaCL); //See 
> http://osdir.com/ml/mozilla.devel.jseng/2002-06/msg00037.html
>
>         var callBackClass = new customPackages.com.mycompany.MyClass({
>                name: function(arg1, arg2) {
>                     //Some code here
>                 }
>             })
>     } catch (e) {
>         log.error(e)
>     } finally {
>         cx.setApplicationClassLoader(savedCL);
>     }
>
> We do it this way, as something dynamic is needed, thus we cannot set 
> the classloader when instantiating the scriptengine.
>
> @Hannes, Jim: tnx for the insight. Glad to hear that some ES6 features 
> are already targeted for 8u40. I understand that implementing the 
> whole of ES6 is a major task. Wish I would be a person to be able to 
> provide patches, but I'm afraid that's not something up my alley.
>
> Paul
>
> On 8/1/2014 8:49 PM, Jim Laskey (Oracle) wrote:
>> Hi Paul,
>>
>>
>> On Jul 31, 2014, at 4:43 PM, Paul Bakker <pgbakker at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Maybe not the right place to ask these questions, but I could not 
>>> find another place to ask them.
>>>
>>> 1: What is the roadmap of Nashorn when it comes to EcmaScript 6. The 
>>> spec if quite final, mostly bugfixing. Assuming that at some point 
>>> EcmaScript 6 will be supported in Nashorn, what is the policy to 
>>> porting support back to existing Java versions? Can we expect to see 
>>> EcmaScript 6 support in Nashorn in Java 8, or would such features 
>>> only become available in new Java versions (so 9 or even 10)?
>> In general, we like to move forward and try to avoid back ports when 
>> we can; bug fixes - sure, features - not so much.  And, it's not just 
>> about marketing, it's really about logistics.  At the development 
>> level, features (even simple ones) have dependencies with other 
>> changes in the software.  A back port can haul a lot of ancillary 
>> code with it (and not just Nashorn.)  At the product level, back 
>> ports require support from all the usual suspects, PM, SQE, Security, 
>> DOC, Sustaining, ... .  Releases are a lot of work.  Multiplied 
>> across platforms and releases, it is huge.
>>
>> In the past, there has been a tendency to go slow with JVM releases.  
>> However, JDK 8 has had the fastest/largest adoption of any JVM 
>> release.  We'd like to see that trend continue. Keeping the arrow 
>> pointing forward is the right thing to do.
>>
>> ES6 will be a slow rollout, based on what we sense is important to 
>> the JS community.  Not being specific, you will see some ES6 features 
>> in JDK 9.  More ES6 features will follow with update releases.
>>
>>> 2: We currently integrate with Rhino directly (not the version what 
>>> was shipped with Java). One of the features we use is being able to 
>>> load instantiate Java classes from JavaScript using a custom 
>>> classloader, using the new Packages(classLoader) syntax (see 
>>> http://osdir.com/ml/mozilla.devel.jseng/2002-06/msg00037.html). Is 
>>> this supported in Nashorn so way or the other?
>> Sundar has responded for this question.
>>
>>> TIA,
>>>
>>> Paul
>> Cheers,
>>
>> -- Jim
>>
>>
>>
>>
>