Nodyn – Node.js for the JVM(nodyn.io)
nodyn.io
Nodyn – Node.js for the JVM
http://nodyn.io/
15 comments
Will it have the concurrency features of Vert.x? I was hoping that jxcore [1] (aka NodeJX) would bring these to node but this seems like a better alternative.
[1]: http://jxcore.com/
edit:
> All that with vert.x's powerful clustering technology built right in
I think I missed that part. Sorry =)
[1]: http://jxcore.com/
edit:
> All that with vert.x's powerful clustering technology built right in
I think I missed that part. Sorry =)
Given the asynchronous programming model that node encourages, how have you found integrating with the traditional Java programming model that most of the Java ecosystem uses?
Vert.x has something called a 'worker verticle' that can run blocking IO in a thread pool. You'd communicate with the worker by passing messages on the event bus asynchronously. It makes integrating those kind of services fairly straight forward, but obviously you'd switch to actual async APIs if available.
Yes this is what I've been looking for. I gave up trying to get Vert.x running before, but I'm willing to give this a try.
Cool and if I combine it with http://www.scala-js.org/ I'll be able to run scala on the jvm.
I'm not sure what you meant here, considering Scala already does run on the JVM.
thatsthejoke.gif
Question from a novice-ish developer: What is the purpose of porting things to the JVM? I had this idea before that porting things like Ruby or Rails to the JVM was meant to offer ruby the advantages of having a java core (better threading, garbage collection, faster). But, as I understand it, Node is faster than JVM languages? What are the other advantages gleaned from porting?
e: Thank you guys for the answers, definitely makes a lot more sense now.
e: Thank you guys for the answers, definitely makes a lot more sense now.
The JVM gives you very good JIT, GC, threading, manageability (profiling, debugging, memory inspection etc), scalability to huge machines, a huge ecosystem of software and has basically solved every real-world deployment problem. (Maybe apart from memory utilization!) It is definitely possible to beat the JVM on any one of these facets, but to consistently beat it on all of them is a _lot_ of work. (I'm not sure which benchmark you're referring to where Node beats the JVM, but I suspect it's relatively 'focused'.)
To my mind, the idea of porting is that you face a choice: you can recreate the JVM functionality in your own runtime, or you can port to the JVM. Porting to the JVM is certainly non-trivial, but you then get thousands of man-years of work in return. It's certainly worth doing a project to see whether the porting effort pays off; especially if this done concurrently with working on the language's 'native' runtime.
To my mind, the idea of porting is that you face a choice: you can recreate the JVM functionality in your own runtime, or you can port to the JVM. Porting to the JVM is certainly non-trivial, but you then get thousands of man-years of work in return. It's certainly worth doing a project to see whether the porting effort pays off; especially if this done concurrently with working on the language's 'native' runtime.
but to consistently beat it on all of them is a _lot_ of work.
As long as you aren't native, that is.
Although that's unrelated to the discussion at large.
As long as you aren't native, that is.
Although that's unrelated to the discussion at large.
Even then it's not that easy. A non-optimizing C compiler will have a hard time beating the JVM's slew of optimizations.
A non-optimizing C compiler
Is there a C programmer on the planet that does production builds with a non-optimizing compiler? How is your comparison even remotely relevant to the GP?
Is there a C programmer on the planet that does production builds with a non-optimizing compiler? How is your comparison even remotely relevant to the GP?
I believe the GP is referring to writing a non-optimising compiler in C. Not compiling your C code using a non-optimising compiler.
That's mostly true, but just like managed languages can leverage JVM, native languages can leverage LLVM.
The advantage of going the native route is that it gives you improved observability and post-mortem. The JVM is a VM (Java's) inside a VM (the OS's), and that additional layer doesn't come for free.
The advantage of going the native route is that it gives you improved observability and post-mortem. The JVM is a VM (Java's) inside a VM (the OS's), and that additional layer doesn't come for free.
Most commercial JVMs also have native compilers for Java, and there are a few projects to run JVMs directly on top of hypervisors without OS in the middle.
Some of those are actually LLVM frontends.
Some of those are actually LLVM frontends.
I'm referring to the open Hotspot which almost everyone uses, not some specialized JVM products which are closed-source. You do bring up an interesting point though.
As for the type of hypervisors you're referring to, those things are effectively half-baked operating systems. That's why something like KVM is better -- you're not pretending to be a non-OS while slowly reinventing a wheel that the *nixes have and always will do better.
I think we're beginning to wander massively afield though! :)
As for the type of hypervisors you're referring to, those things are effectively half-baked operating systems. That's why something like KVM is better -- you're not pretending to be a non-OS while slowly reinventing a wheel that the *nixes have and always will do better.
I think we're beginning to wander massively afield though! :)
Hypervisors are older than UNIX, as the first ones date back to the OS/360.
Very thorough answer, thank you :]
Naive (and mostly ignorant) programmers make a habit of sh*tting on the JVM and the Java platform in general.
My usual response regarding the merit of the JVM is this: there is a reason there's jvm on the server, desktop, on your phone, on the rovers on mars and god knows on how many mission critical systems.
And no it isn't because of great marketing, which is another common and lame response from JVM detractors.
The JVM is an impressive engineering effort and the eco-system spawned by it is currently unrivaled.
With the new trend of porting other languages (ruby,python,js..etc) to it, the I see the JVM as the middleware over which most future software would be built.
My usual response regarding the merit of the JVM is this: there is a reason there's jvm on the server, desktop, on your phone, on the rovers on mars and god knows on how many mission critical systems.
And no it isn't because of great marketing, which is another common and lame response from JVM detractors.
The JVM is an impressive engineering effort and the eco-system spawned by it is currently unrivaled.
With the new trend of porting other languages (ruby,python,js..etc) to it, the I see the JVM as the middleware over which most future software would be built.
Node is actually much slower than Java. True, the JavaScript implementation on the JVM is slower than V8 (even Nashorn, the new JavaScript engine included in Java 8). Of course, the main motivation is, as others have said, integration with the huge Java ecosystem, but being able to drop down to Java for performance (when you need it) is a lot easier than writing native V8 modules.
but being able to drop down to Java for performance (when you need it) is a lot easier than writing native V8 modules.
There's a node-ffi package, although it has some overhead from the call itself.
https://github.com/rbranson/node-ffi
There's a node-ffi package, although it has some overhead from the call itself.
https://github.com/rbranson/node-ffi
Imagine that you just started a new job at a big company. It's a "Java shop". You're allowed to use any technology stack you want for your apps, and all the other apps have APIs, but there's hundreds of useful Java libraries that already exist for talking to these APIs.
This would allow you to use NodeJS but still leverage the existing Java libraries, not requiring you to rewrite them.
This would allow you to use NodeJS but still leverage the existing Java libraries, not requiring you to rewrite them.
> Question from a novice-ish developer: What is the purpose of porting things to the JVM?
Interop with the things that already exist in the Java ecosystem.
> I had this idea before that porting things like Ruby or Rails to the JVM was meant to offer ruby the advantages of having a java core (better threading, garbage collection, faster).
To the extent that those were effects of porting Ruby to the JVM they were mostly secondary, Java interop was the key feature (Rails, BTW, wasn't ported to the JVM, it just runs anywhere you have a functional Ruby implementation -- heck, before Ruby had executable specs, the test for a functional implementation was pretty much "does it run Rails".)
Interop with the things that already exist in the Java ecosystem.
> I had this idea before that porting things like Ruby or Rails to the JVM was meant to offer ruby the advantages of having a java core (better threading, garbage collection, faster).
To the extent that those were effects of porting Ruby to the JVM they were mostly secondary, Java interop was the key feature (Rails, BTW, wasn't ported to the JVM, it just runs anywhere you have a functional Ruby implementation -- heck, before Ruby had executable specs, the test for a functional implementation was pretty much "does it run Rails".)
It seems like a major motivation for this project is to be able to use Java libraries from Javascript (a la Jython). There are a non-negligible number of libraries that only exist for Java, and being able to harness those from JS sounds nice to me, even if it means taking a performance hit.
Ohhhh, so one would just make like a node interface for some Java library, and it would be available for use in any JVMNode app?
This makes a lot of sense.
This makes a lot of sense.
Jruby lets your ruby code use any Java library and gui toolkit. This is quite useful.
Also, if you work at a Java shop having stuff run on the JVM affords a way to sneak in new tech. :)
Also, if you work at a Java shop having stuff run on the JVM affords a way to sneak in new tech. :)
In my opinion (I'm a Java dev), the main benefits are being able to run RoR apps on TorqueBox[1] or some other JRuby server[2] and benefit the clustering, HA and other stuff that go with it; and 'the use of "true" native threads'[3].
[1] http://torquebox.org/ [2] https://github.com/jruby/jruby/wiki/Servers [3] http://www.restlessprogrammer.com/2013/02/multi-threading-in...
[1] http://torquebox.org/ [2] https://github.com/jruby/jruby/wiki/Servers [3] http://www.restlessprogrammer.com/2013/02/multi-threading-in...
> But, as I understand it, Node is faster than JVM languages?
What is the source for that?
What is the source for that?
Node is more adept at handling many concurrent requests due to its architecture but it's runtime is far slower than the JVM. The vert.x framework that is the basis for this project is based on a similar paradigm to node and is far faster.
Are you really claiming that Node is faster than Java? Source?
to run it 'in the cloud'; most hosting places will allow you to run java only, this restriction is in place so that everything will seem secure and divided into neat compartments.
[deleted]
I personally have been wanting a way to compile ClojureScript to JavaScript without using the JVM. I'd rather just use the existing Node/v8 installation that I have, especially since I don't use the JVM for anything else. I know this project doesn't do that, I'm just throwing my wants and desires out into the wild and hoping they come alive.
Don't forget that ClojureScript macros are written in Clojure. Even if you rewrote the compiler in ClojureScript, it seems like you'd need the JVM to run your Clojure macros (unless you were OK with sacrificing some compatibility).
How is this different than https://avatar-js.java.net/ ?
The focus of avatar-js seems to be to support the avatar project, which seems to be mainly about providing a node like server.
At present, there aren't nice binary downloads for anything that can just run node programs, I had to fiddle about a bit to get something I could play with, and even then, only some programs work - npm for example seems to go into a loop.
https://github.com/kybernetikos/avatarjs-sandbox/tree/master...
At present, there aren't nice binary downloads for anything that can just run node programs, I had to fiddle about a bit to get something I could play with, and even then, only some programs work - npm for example seems to go into a loop.
https://github.com/kybernetikos/avatarjs-sandbox/tree/master...
Same idea, different project.
And different technologies (and possibly different ways of implementation under the hood). Nodyn uses DynJS, this uses Nashorn.
Take it this is Rhino under the hood somewhere, or has someone written a new js engine?
http://dynjs.org/ is, AFAIK, independent of Rhino.
Thanks for that pointer, didn't know of this.
Also for anyone interested in an easy way to use the JVM for other languages, check out crudzilla.com . It is primarily for web development but has basic editor for other development work.
Also for anyone interested in an easy way to use the JVM for other languages, check out crudzilla.com . It is primarily for web development but has basic editor for other development work.
yup, it's independent, you can get more context on why I created dynjs here: http://blog.qmx.me/the-release/
Is there any plan to implement asm.js and JIT to JVM bytecode directly from JS?
After a cursory look through the source, it would appear that it already JITs to JVM bytecode.
asm.js isn't relevant here at all.
asm.js isn't relevant here at all.
Isn't the idea of asm.js that if a program is written according to the spec you can generate simpler and so hopefully faster code? That applies whether you're generating bytecode or machine code.
Sure, but you'd have to generate asm.js in the first place. It's compiler target that also happens to map to a small subset of JavaScript, you're unlikely to find writing asm.js by hand useful.
DynJS could also support asm.js in addition to JavaScript, but that has almost nothing to do with JIT-ing JavaScript applications.
DynJS could also support asm.js in addition to JavaScript, but that has almost nothing to do with JIT-ing JavaScript applications.
Right. I wasn't thinking of this as the _only_ JIT case, but one that could generate faster code by not having to do complex type tracing or inference. Seems like low hanging fruit to detect asm.js and read it directly into a typed AST.
Probably, yes.
Although with invokedynamic, the JVM's object system ends up being remarkably close to that of a dynamic language. This is best seen in JRuby.
Although with invokedynamic, the JVM's object system ends up being remarkably close to that of a dynamic language. This is best seen in JRuby.
Thanks. I'd totally missed that.
Are there any benchmarks of DynJS vs v8? Presumably it's considerably slower, but it'd be interesting to see by what order of magnitude...
None published, but your presumption is correct for the time being.
Neat, I hadn't come across DynJS yet. It would be nice if the landing page mentioned how the project is different from Nashorn and Rhino.
Not in any way trying to troll here, but other than as an intellectual exercise, why on earth would one want to develop in Node on the JVM? Surely Java/Scala/Clojure etc would solve any problem easier and faster than Node on JVM?
What am I missing?
What am I missing?
Nan Pointer Exception
What's the difference between using Vert.x with DynJS and using Nodyn? Nodyn is ment to be a drop-in replacement for Node.js right?
I am still waiting for Node.js on Mozilla Gecko javascript engine (instead of V8).
Is someone working on it?
Is someone working on it?
What would the benefit be?
Apart from "competition"? Mozilla's JS engine has gotten on par with V8.
Any relation to the Node.jar project?
Down already?
Another product without any problem being solved.
V8 is in many regards better (especially memory footprint and ramp-up time) or on par.
> clear access to Java directly in your Javascript.
Who needs this when having access to 50K nom packages?
V8 is in many regards better (especially memory footprint and ramp-up time) or on par.
> clear access to Java directly in your Javascript.
Who needs this when having access to 50K nom packages?
I would venture to guess that interoperability with existing projects and services is important to some people. Also, there are Java libraries which are significantly better than their closest corresponding Node package.
Why would you code in Javascript on the JVM to begin with if you have existing projects and libraries written in java ? that's stupid. If the goal is async IO there is Vert.x and other non blocking servers already. Not even talking about cases when libs require C++ extensions... Can you code in Java on Nodyn? no
EDIT : seems to be built upon Vert.x ? you can already code in javascript with Vert.x
EDIT : seems to be built upon Vert.x ? you can already code in javascript with Vert.x
"that's stupid" is a pretty broad statement. There are many reasons why one may choose to write new software in JS while taking advantage of existing investment in Java. If it doesn't make sense for you, don't do it. But for many it may.
As for coding Java on Nodyn, well, yes you can. That's kind of the point in some ways. You can write Java, package it as a jar and access this from Nodyn. Nodyn itself does this for the Buffer implementation.
Yes, vert.x already supports JS (I maintain the mod-lang-js, mod-lang-rhino and mod-lang-dynjs language modules for vert.x). The idea behind Nodyn is to provide drop-in Node.js compatibility in the Vert.x environment.
As for coding Java on Nodyn, well, yes you can. That's kind of the point in some ways. You can write Java, package it as a jar and access this from Nodyn. Nodyn itself does this for the Buffer implementation.
Yes, vert.x already supports JS (I maintain the mod-lang-js, mod-lang-rhino and mod-lang-dynjs language modules for vert.x). The idea behind Nodyn is to provide drop-in Node.js compatibility in the Vert.x environment.
But if you code JS for Vert.x, you're restricted to Vert.x for life.
This way you write JS for Node and you can run it under either Node or the JVM.
This way you write JS for Node and you can run it under either Node or the JVM.
How much do you trust the nodejs driver compatibility layers for oracle and db2? How about generating Excel files? Nothing comes close to poi yet.
That said, I'd suggest running node wither a service oriented architecture if both were non-negotiable requirements.
That said, I'd suggest running node wither a service oriented architecture if both were non-negotiable requirements.
Nodyn is not yet complete, though I'd like to have a release in the next month that is capable of running express.js apps. It is slower than Node.js, but of course I'd like that to change; and with the JVM underneath, beating Node.js on performance is possible.
Nodyn is built on top of Vert.x (http://vertx.io) an asynchronous polyglot platform which excels on the Techempower benchmarks. The javascript runtime is DynJS - a new JS runtime for the JVM which is independent of Oracle. Though it's admittedly slower than Nashorn at the moment, we hope for that to change.