Use Nashorn instead of Rhino (if available)

[candrews]

It would be great if Trireme could use Nashorn instead of Rhino if Nashorn is available. I think ideally, there should be a setting to specify the name of the engine to use, then if the engine isn't specified, Nashorn should be tried followed by Rhino.

Since Nashorn is faster and provides more javascript features than Rhino, it seems to be the clear choice (when there is one), and with Nashorn backports popping up, it may be a more realistic option soon even for users of Java < 8.

[gbrail]

Yes -- this is important to me (and others at Apigee) for the reasons that you mention. To me, the biggest reason is not the performance (although I have high hopes there) but the fact that there is an actual team working on the implementation and they are keeping up with the Java spec. My fear with Rhino is that as new and non-standard V8 features creep in to popular Node modules, they won't run on Rhino, and at least the Nashorn team has an incentive to work on them.

As for how we do it, well, one could argue that we could have built Trireme entirely in a way that uses only the standard "javax.script" interfaces, but we didn't. (At the time I didn't think it was possible, and perhaps it was in retrospect, but the way we did it came out pretty clean IMHO.) So that means that lots of code has to change in lots of places to switch to the Nashorn way of doing things.

So I think that what we'll end up with is a new project that is 90 percent, like Trireme, but perhaps different and I hope simpler in some places. Stay tuned and I hope I have something in the next weeks or months, and at this point we would certainly welcome help!

(BTW, I didn't get a lot of encouragement from the Nashorn project team about the various Java 7 backports, although if they work I imagine that we could make the new Trireme compatible.)

[magro]

+1

[mwaylabs]

+1

[imikushin]

I've put together a Node.js on Nashorn using Scala. Only the modules are implemented, but it works just fine for purely functional libs. I'm thinking about reimplementing it just for Java. Check it out: https://github.com/KillingBilling/junction

[panga]

+1

[gbrail]

Been working on this for a long time, actually. Nashorn and Rhino are really quite different, especially the way that we use it to run Node.js. As a result, I'm working on Nashorn support in a separate project called "rowboat."

https://github.com/apigee/rowboat

Sadly, if the idea is that by switching to Nashorn we will have performance that is closer to that of regular Node.js, then at the moment my hopes have been dashed. Rowboat right now is much slower than Trireme and it's not exactly clear why.

[dasniko]

Hi @gbrail

Nashorn is still slower than Rhino when invoked freshly, without warming up. Once the engine is warmed up, there's much better performance than Rhino! Several tests showed that to me and to others. It's also a known fact in the Nashorn team. If you have any doubts or questions regarding the performance of Nashorn, you should talk to Marcus Lagergren of the Nashorn team!

Additionally, Nashorn gains more performance with the next Java release 8u40 with its predictive "optimistic typing": https://blogs.oracle.com/nashorn/entry/nashorn_performance_work_in_the

I'd love to see some more Node.js runtimes on the JVM using Nashorn. Avatar.js from Oracle is a good approach. Also Nodyn from Red Hat is very interesting. Despite they are using DynJS as a JS engine, they already started to implement a Nashorn version!

[gbrail]

I've been making progress with "rowboat," which uses some of the guts of Trireme but has a lot different to support Nashorn. On 8u20, an HTTP server is a lot faster than Trireme, whereas for some undiagnosed reason (probably my code, but there are no smoking guns in a profile) an HTTP client is vastly slower.

I'd be more than willing to help parcel out coding tasks to anyone who would like to contribute to either Trireme or Rowboat.

On Mon, Dec 22, 2014 at 11:37 PM, Niko Köbler notifications@github.com wrote:

Hi @gbrail https://github.com/gbrail

Nashorn is still slower than Rhino when invoked freshly, without warming up. Once the engine is warmed up, there's much better performance than Rhino! Several tests showed that to me and to others. It's also a known fact in the Nashorn team. If you have any doubts or questions regarding the performance of Nashorn, you should talk to Marcus Lagergren of the Nashorn team!

Additionally, Nashorn gains more performance with the next Java release 8u40 with its predictive "optimistic typing": https://blogs.oracle.com/nashorn/entry/nashorn_performance_work_in_the

I'd love to see some more Node.js runtimes on the JVM using Nashorn. Avatar.js from Oracle is a good approach. Also Nodyn from Red Hat is very interesting. Despite they are using DynJS as a JS engine, they already started to implement a Nashorn version!

— Reply to this email directly or view it on GitHub https://github.com/apigee/trireme/issues/50#issuecomment-67928028.

greg brail | apigee https://apigee.com/ | twitter @gbrail http://twitter.com/gbrail

[gbrail]

This is a great thread that got a lot of interest. The "rowboat" project is an attempt to do this. It's a bit out of date and needs some TLS to get it finished, but a lot of modules work:

https://github.com/apigee/rowboat

Given how different Rhino and Nashorn are, I don't think it makes sense for Trireme to try and mode-switch in this way -- instead, rowboat is that project.

There is a "kernel" component of Trireme that Rowboat shares, so that it can take advantage of some of the work that we did on NIO and other things.

[mdedetrich]

@gbrail Is there any update on this (or maybe more precisely, the status of rowboat?)

[gbrail]

Honesty we made more progress this year making Rhino more compatible with ES6 than we made on running Trireme on Rowboat. I also don't know the status of ES6 features in Nashorn, but again it's been easier to make Rhino more compatible, and there have been a few people working on other missing ES6 features. So not much progress has been made on Rowboat.

On Tue, Dec 22, 2015 at 4:10 PM, Matthew de Detrich < notifications@github.com> wrote:

@gbrail https://github.com/gbrail Is there any update on this (or maybe more precisely, the status of rowboat?)

— Reply to this email directly or view it on GitHub https://github.com/apigee/trireme/issues/50#issuecomment-166766269.

Greg Brail | apigee https://apigee.com/ | twitter @gbrail http://twitter.com/gbrail @apigee https://twitter.com/apigee

[mdedetrich]

Thanks for the update, just wondering what the status of this is. Looks like rowboat will probably be a medium/long term proposition