We're happy to announce that we've been working on "Trireme," which is a set of Java libraries that makes it possible to run Node.js applications on the Java VM.
Please check it out on GitHub: https://github.com/apigee/trireme and on Maven Central: http://search.maven.org/#search%7Cga%7C1%7Cio.apigee.trireme There is some documentation on GitHub and we're happy to answer more questions, but here are the answers to some frequently-asked questions: *Why would I use Trireme?* Trireme is specifically optimized to make it possible to embed Node.js applications inside a Java VM and control their access to the outside world. It also has features that make it possible to embed Trireme inside a larger HTTP container. For instance: - Trireme can listen on the network directly, or it can be configured to use an "HTTP adapter" that lets existing apps built using the "http" module work inside an existing HTTP container. - Trireme can load Java libraries which can then appear in the module search path just like regular Node modules. - Trireme can be configured to run inside a "sandbox" that controls exactly what parts of the filesystem and network each script is allowed to access. - Trireme uses a Rhino feature that makes it possible to throw an exception if a script stays within a single Node "tick" for too long -- for instance if it is stuck in a CPU loop In other words, Trireme is useful if you already have a Java-based infrastructure, and existing Java code, that you want to take advantage of, while adding the ability to run Node.js applications. *Why would I not use Trireme?* If you don't have a Java-based infrastructure that you need to keep supporting, then Trireme doesn't make sense. Although you can run ordinary Node.js programs inside Trireme from the command line, and they (mostly) behave just the same as regular Node, there's no real advantage to doing this unless you have existing Java containers you want to use or Java code that you need to access from inside Node. *How is it different from other Node-on-Java projects?* Primarily, the focus on embeddability makes Trireme different from just "porting Node to the JVM." In addition, Trireme works now, on Java 6 or above. It depends on Rhino, SLF4j, and Bouncy Castle, and nothing else. There's no native code. (And Bouncy Castle is optional -- unless you're dealing with custom TLS certs or some crypto functionality Trireme can run without it.) *Why did you use Rhino?* Rhino is the most complete and stable JavaScript runtime for Java today for Java 6 and 7. We would love to learn more about Nashorn but at least here we are not ready to run on Java 8. *How fast is it?* Trireme is not as fast as regular Node, primarily because Rhino is much slower than V8. How much slower depends. Also, keep in mind the various strengths and weaknesses of Java. If you want to benchmark "console.log('Hello, World!');" you should expect that Trireme is vastly slower than regular Node. For a long-running server the difference is smaller. *How complete is it?* Trireme is fairly complete and runs the vast majority of Node modules that we have tried, including Express. Major holes include: - crypto isn't completely finished - cluster isn't implemented - the debugger and repl don't really work (and the debugger may never work) See the GitHub repo for more. (Trireme currently passes most of the tests in the Node.js "simple" and "pummel" test suites but not all.) *Why did you do this?* We have an extensive Java infrastructure here, and a lot of existing code that we'd like to efficiently reuse. At the same time, we'd wanted to add support for Node.js applications. Trireme is our current way to solve this problem. *What's next?* Trireme is pretty far along but it needs to be completed in several areas: - Continue to work on test coverage and get as close as we can to 100 percent of the *relevant* Node.js tests. - Continue to improve the test infrastructure so that we can confidently say how much is covered versus not - Complete implementations of the modules that are incomplete - Test performance and improve where we can - Build samples, especially around embeddability Longer-term, we need to address what to do about the Java runtime: - Continue to invest in Rhino and work with the community to bring it more up to date? - Or, port to Nashorn when it is ready? - Or, look at DynJS? Finally, there may come a time when the various Node-on-Java projects need to come together and share code. ----------- Greg Brail Apigee @gbrail -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
