Who, What, How?
Nodyn is Red Hat's implementation of Node.js on top of the Java Virtual Machine. Currently Nodyn is tracking the 0.12 release of Node.js. The project is lead by Lance Ball with Bob McWhirter pitching in.
Lance and Bob are part of the team responsible for TorqueBox, and are familiar with taking languages and frameworks that don't run on the Java Virtual Machine already, and making them run on the JVM.
The foundations of Nodyn include DynJS, Netty, and Vertx. Initially Nodyn was conceived as a clean-room implemention of the public-facing APIs exposed by Node.js, but this route turned out to be problematic for a few reasons:
- The public-facing APIs were not always very well-documented.
- Various NPM modules would use un-documented APIs.
Given this new strategy, the public-facing APIs provided by Node.js, as
implemented in the various .js files in their
lib/ directory, are also
exactly the same in Nodyn. Also, it turns out that the API surface defined
by the various
process.binding(...) objects is significantly smaller than
the public-facing APIs, reducing the amount of work required by the Nodyn team.
For instance, in a clean-room implementation, all of
http.js would need to be
implemented, from scratch. By building upon actual Node.js sources, the
http.js module requires only an
HTTPParser implementation, and builds itself
on top of the
Some of the Node.js APIs, particular
child_process and much of
fs rely upon
facilities not present in the JVM. Nodyn leverages the jnr-posix library (the
same library used by JRuby) to provide capabilities for working with integer-based
file-descriptors, and sending these file-descriptors to forked child processes.
While we've answered the Who, the What and the How, we should still address the Why of Nodyn. Node.js is, on the outside, a single-threaded framework. Java can handle threads without a problem. But Java can still perform better with reactive, asynchronous frameworks. Just because Java can use threads like magic, each thread does still have a certain amount of overhead (stack space, context-switching, etc), so if we can avoid using them, that's great!
Additionally, just as Node.js likes to say "Node.js is multi-threaded everywhere, except your code", Nodyn follows the same route. There are lots of threads inside of Nodyn, but only a single thread ever executes your code.
That is great, but it doesn't doesn't answer the question, does it?
The JVM has a lot going for it. There's a ton of libraries existing for it. There's tons of enterprises that are already familiar with running JVM-based stacks in their data-centers. And these guys would like to board the hype train of Node.js. Nodyn allows that.
Additionally, while it's convenient to run multiple Node.js processes to use many processors, Nodyn will soon provide the ability to run multiple Node.js "processes" within a single JVM process. Nodyn has been constructed, from the ground up, without any shared global state or variables. It is super-simple to embed many completely separate Node.js runtimes inside the JVM using Nodyn.
We still need to figure out how Nodyn lives within the large Node.js community and ecosystem. Specifically, it'd be great to be able to have JVM-flavored NPM modules, possible as alternative to C++-based modules.
The Ruby world saw this transition, with the support of
-java gems being added
to the RubyGems packaging system. A single named gem may have both a C-based version
or a Java-based version.
Additionally, there are still parts of the Node.js core APIs that we haven't necessarily implemented. Feel free to pitch in!