search

apigee / trireme

Embed Node.js inside a Java Virtual Machine
Other
479 stars 48 forks source link

Update trireme to latest Node #191

Open ralleman opened 5 years ago

ralleman commented 5 years ago

I was considering porting trireme to GraalVM which is mostly ES2019 compliant (i.e. scrapping Rhino), but trireme is supporting such an old version of Node that it's not worth the effort. Would Apigee be interested in starting a new project that does this, e.g. Trireme2?

gbrail commented 5 years ago

Sorry I didn't answer this sooner.

My employer is migrating away from using Trireme and there's no one, including me, assigned to work on Trireme. Of course, I'm happy to merge work done by others.

The biggest limitation to upgrading the Node version in Trireme is indeed the speed at which JavaScript changes. I continue (with a lot of help) to maintain Rhino and it continues to gain language features, although it is not ready to run modern Node code yet.

I few years back I worked on "rowboat" in this same GitHub org, which was an attempt to get Trireme working on Nashorn. It was 100 times faster for some use cases and 10 times slower for others -- I never figured out why. However, the Java embedding models of Rhino and Nashorn are so different (at least the way that Trireme does it) that there was not much reusable between the two. I suspect you'd get the same issue with Graal.

Finally, the GPL makes GraalVM pretty hard for a lot of organizations to incorporate into open source.

On Sun, May 19, 2019 at 5:27 AM ralleman notifications@github.com wrote:

I was considering porting trireme to GraalVM which is mostly ES2019 compliant (i.e. scrapping Rhino), but trireme is supporting such an old version of Node that it's not worth the effort. Would Apigee be interested in starting a new project that does this, e.g. Trireme2?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/apigee/trireme/issues/191?email_source=notifications&email_token=AAD7I22RV5GEQXIIA4EEQH3PWFBTZA5CNFSM4HN4LNGKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GUSSWKA, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD7I24T6GKJASTKZNHRRI3PWFBTZANCNFSM4HN4LNGA .

ralleman commented 5 years ago

Thanks for the response @gbrail.

The biggest limitation to upgrading the Node version in Trireme is indeed the speed at which JavaScript changes. I continue (with a lot of help) to maintain Rhino and it continues to gain language features, although it is not ready to run modern Node code yet.

This is where GraalVM is great, because the team is keeping up with the latest changes in JavaScript, so there's no need to do anything with JS support as a developer of a Trireme alternative. Keeping up with Node changes, is of course, a different issue.

It was 100 times faster for some use cases and 10 times slower for others

The GraalVM team are doing a lot of work in getting the performance of JS comparable to NodeJS, so hopefully it's not something anyone needs to worry about. In any case, performance is less important than capability IMO.

Finally, the GPL makes GraalVM pretty hard for a lot of organizations to incorporate into open source.

Actually GraalVM is GPL with classpath exception, which makes it usable as an embeddable library in commercial applications. Being owned by Oracle though, there's always the worry that Oracle will change the licensing. I think the GraalVM team would be pretty upset if Oracle locked the licensing down because if they gave it a regular GPL license, it would probably result in the end of the project. At this stage, I can't see that happening.

caoccao commented 3 years ago

Changing JS engine is really hard. Usually, that implies throwing away half of the design. I managed to embed latest Node.js LTS in JVM in this project Javet.