Ringo and Nashorn as engine

[darrencruse]

hope this isn't annoying feel free to close if so...

I was just thinking - I assume the lack of movement towards a nashorn port reflects that it is a hard problem - that it's in some areas more of a "rewrite" than a "port".

But I'm also guessing there's been some thought about what it would require, and in my case I'd be willing to contribute some effort if I was more confident of what the scope of all would be required and that there really is a path to a succesful outcome.

In that spirit I wanted to suggest could there be a wiki page here to gather such thoughts?

e.g. How much of ringo is javascript versus how much is java...

and of the java classes which would be the first to need to be rewritten (I assume that "RhinoEngine" class that invokes the javascript engine would be an obvious starting point).

And then of the javascript maybe a list of the obvious incompatibilities between the Mozilla Rhino javascript flavor and the Nashorn ES5 flavor that would need to be changed.

That kind of stuff...

Or if the above is idealistic on my part - i.e. that the port to Nashorn really is just a lot lot lot of work so much that it may never happen, if such a wiki page kind of articulated exactly why that is I think it would be helpful for people to refer to that as well.

Just a thought...

[botic]

Rhino is indeed a fundamental part of Ringo and it would be more a rewrite of the core than just a small replacement of the engine. At the moment a lot of Rhino-internal stuff is visible at various places in our source. Nashorn encourages a more separated approach between the engine and the runtime environment, based on Java's scripting APIs.

Nashorn doesn't implement some ES6 features which we use at a lot of modules, but there will be some progress toward JDK9. @hns wrote some notes about that: http://openjdk.java.net/jeps/292

For the moment a roadmap could be (but there is no "official agreement" on it yet, just some talks and e-mail discussions):

• 1.0.x release based on the current master this fall
• 1.1.x implements bug fixes and smaller updates to Ringo's modules
• 2.0.x new httpserver by @grob and rewrite of httpclient in JDK9 style
• future releases: Nashorn based on JDK9

Nashorn will replace Rhino in the future, but I don't see it now. There a many ES6 features which are not implemented in Nashorn atm and these are essential for a migration to Nashorn. I hope that helped on this issue.

[darrencruse]

Thanks botic your comments were helpful.

Reading them reminded me of some things behind my questions above that I didn't say - not sure how constructive for me to say them but maybe it gives some context to where I was coming from:

a. We really had good success with Ringo at my former employer within our little group...
b. But outside our little group it was always a tough sell - Ringo being so little known and having so little community.
c. We found Ringo pretty reliable but I do feel the perception among the java community is that Rhino is now outdated (and had poor performance) so I think that too makes it harder sell to new people.
d. I know at ORF you guys use Ringo internally right - this is a negative sounding question but I'm curious: do you guys have much hope or expectation of Ringo ever gaining a larger following?
e. The complement to me asking about Ringo porting to Nashorn has been me googling looking for status of node.js on the JVM - the lead prospect for that seemed to be the nodyn project which started with it's own "dyn.js" engine but was hoping to port to nashorn as well. But that project also seems to have stalled.
f. It seems obvious to me that node.js running on Nashorn is what could really grab some attention and get some community behind it it would be awesome if somehow your ringo team and the nashorn team and the nodyn all aligned on that goal. That would be an effort I could really get excited to contribute to.

But your comments do help me appreciate none of this is turning out to be easy right...

And I guess in your case you guys are focused on keeping Ringo up for your use at ORF regardless of any wider popularity right.

Sorry rambled a little above just kind of thinking out load fwiw.

[botic]

I agree that Rhino is not known to be the fastest engine on the planet and that Rhino is indeed slower in the long run. But still, Nashorn had in the past some issues with its warmup period. A thing which Rhino managed quite well at that time. As long as Nashorn doesn’t implement features of ES6 which are in Rhino since years, I see troubles for a potential migration. The team behind Nashorn is working on these features and I see a good chance to have them all in the next big release together with JDK 9.

We are using Ringo at ORF at a lot of places and the installation base grows from project to project. I think it would be much harder for Ringo if the main development process would be still on the server. But in my day to day business I see a huge amount of my work going into the frontend, which is indeed based around Node and the whole tooling. The server side became a very thin layer, mostly just producing static JSON or a dynamic JSON-API. Since Ringo allows us to use whatever bulletproof Java library together with JavaScript, we can implement these things very quick and stable.

You are right: Ringo doesn’t have a huge install base and community. I don’t have a count and I really don’t care at the moment. When I give a talk about Ringo at local meetups in Vienna and around Austria, the feedback is: yes, sounds quite interesting and I understand your use case, but we are already on Node and Node is the big player in this area. That is true and I fully agree, but especially if someone runs a JEE stack, this point is not valid anymore. Their interest in Ringo is much higher and at least they are keeping it on the radar. Sometimes I’m happy about the current state, which gives us a lot of freedom and makes decisions easier, sometimes I’m worried that there is not more attraction and new big users.

At the time when Helma NG was around and Node just started, there would have been a chance to get more attention and progress. But a big disadvantage of the whole project was that all of the core team was sitting around central Europe and not in the valley. That’s a huge drawback for every interesting project nowadays, but it’s an ugly truth. If you or some key users are not present at the hot shit spots, gaining the important new users is hard. And don’t forget that the JS-JVM-world at that time was separated into multiple projects, where the only survivor is Ringo. The other users focused on Node and its non-blocking IO approach hit the masses at the right time. Ringo in contrast has its legacy with Helma and Helma NG, so our core is extremely stable and a true racehorse in our projects. Our focus is on a very stable production environment, where we can run our applications with as little maintenance as possible. Here Ringo does a great job. We don’t use containers or similar technologies right now, so Ringo is optimized for our on-premise infrastructure.

Since the dev power behind Ringo is limited and the clear focus is on the stable 1.0 release, I cannot give you a more positive outlook on Nashorn and Ringo for the next months. We follow the development of Nashorn on a daily basis via Twitter and the mailing list, but we are not actively involved in the engine.

[sclee15]

i agree with @botic.
nashorn is a good engine but it doesn't covers ES6 stuff yet
and also the performance gain is not better than node.js
then i would choose full java interoperability to some performance gain.
https://ariya.io/2014/03/nashorn-the-new-rhino-on-the-block

[darrencruse]

Thanks a lot for your comments @botic. I'll keep an eye on things and what happens after JDK9 with Nashorn ES6 features.

And one small addition re my post above I'd forgotten to mention this other project "trireme" that is also attempting node.js atop rhino:
https://github.com/apigee/trireme

And trireme does have an experimental nashorn version "rowboat":
apigee/trireme#142

(not relevant to ringo so much but just for completeness if somebody reads this thread in the future).

Thanks again,

Darren

[botic]

Afaik is the apigee team the driving force behind minor changes in Rhino. That's why we have a Rhino 1.7.7.1 release this year and I still see some progress in the project. But that happens from time to time, there is no continuous development. This is also a good reason to consider Nashorn in the future. And as you might know, Hannes (creator of Helma and Ringo) is working on Nashorn at Oracle. So I hope he will give me and the other devs some tips when we start with the migration.

[botic]

• A good overview over Nashorn: Riding the Nashorn: Programming JavaScript on the JVM
• What Nashorn will implement in JDK9: JDK-8066046

[botic]

Looks like Oracle found a way to use V8 as an engine under the JVM: https://www.youtube.com/watch?v=-JLhwsbMvjQ

[mslinn]

I'm interested in using Nashorn to run node.js code. No idea what I am getting into yet. Since ringojs appears to still be committed to Rhino, anyone interested in working on Nashorn with me should check out cli-loop.

[botic]

I think this is not the place to point to your project. Ringo is not going to support Node-specifics and there is no path to Nashorn worth the negative consequences on existing applications. So I’ll close this issue for the near future and if anything regarding Nashorn is still unclear, just create another one.