Abstract out hard dependency on DynJS about nodyn HOT 8 OPEN

@lance Hi Lance. Any comment on this? I'm not too bothered how it's done, but getting nodyn to work on Nashorn is still important for Vert.x

from nodyn.

At this point, most (but not all) of the DynJS dependencies have been removed. We have not tested using Nashorn yet, but based on recent attempts to build https://github.com/vert-x/mod-lang-nashorn indicate there are issues in the current version of nashorn which render it incapable of using the vert.x Java API. Specifically, nashorn at this point appears unable to decide between overloaded method handles which take a String or CharSequence.

For example, let's say you have a Java class that looks like this:

package com.me;
public class Thingy {
    public void doSomething(String s) { 
        // code here
    }

    public void doSomething(CharSequence cs) {
        // more code
    }
}

And you try to use it in nashorn like this:

var x = new com.me.Thingy();
x.doSomething('foobar');

Nashorn will fail as it is unable to determine which method it should call. In this case, DynJS chooses the method taking a String. There are a number of Java classes in Vert.x which suffer from this problem - e.g. MultiMap.

So, while I am still making efforts to remove DynJS dependencies, there are issues with nashorn I have not yet resolved.

from nodyn.

Maybe ask on the nashorn-dev list?

from nodyn.

Who is maintaining mod-lang-nashorn these days?

from nodyn.

I am

from nodyn.

Lance,

I had a twitter conversation with some of the Nashorn team today, and it was mentioned that you can force the specific Java method to call from Nashorn JS if you like:

https://twitter.com/sundararajan_a/status/484627566985101313

I think this might be useful in resolving the issue with Nashorn defaulting to an undesired overloaded Java method.

from nodyn.

Just to note that I've been trying out the nashorn branch of this project, and it works pretty well. I have Nodyn running a Gulp build to compile a large amount of LessCSS and run it through the Autoprefixer postprocessor. The same build with DynJS was still chugging away at regexes after half an hour.

So my vote is for bringing in that branch (while leaving DynJS as the default runtime), so that people can choose.

from nodyn.

Is there merit in making nashorn the default runtime if you are running JDK8? Its basically the fastest java runtime for JDK, and it is something that will receive much more support (compared to Rhino or DynJS)?

I would have little qualms in packaging nodyn for JDK 1.7 and lower, and another for JDK 8, with JDK 8 just supporting Nashorn.

from nodyn.