Nashorn Roadmap & Rhino migration question

[Paul Bakker]

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
>
>
>
>