lhofhansl edited this page Dec 23, 2010 · 29 revisions
Clone this wiki locally

Please see Rhinode II

RhiNode is a wrapper around Java's NIO implemented in Javascript. The API is heavily inspired by the excellent node.js API.

The aim of this project is not to be a 100% node.js compatible implementation on Rhino (although it might go that way). There are other projects that attempt to do this (one is "rhinode" hosted on github as well).

The implementation is pretty straightforward.

  • RhiNode sits on top the Rhino Javascript engine (which is implemented in Java).
  • Buffer management is based on NIO buffers.
  • Readbuffers are retrieved from a "pool of bytes" which are never reused (that way a buffer can be passed on and held by a caller). The byte pool is allocated in small 64k chunks.
  • Writebuffers are implemented as "ByteBufferOutputstream" (similar to ByteArrayOutputstream, but backed by ByteBuffers).
  • The HTTP module supports 1.1 and 1.0 clients and servers.
    • The HTTP state management is done using Javascript generator functions. This allows for network buffer to be pumped through the generator as data becomes available from the network.
  • The FS module currently only "simulates" Readable/Writable streams. (NIO does not have selectable FileChannels, so file streams are always considered readable and writable.)

Performance is already pretty good (Benchmarks), even though the main event loop and other tight loops are still running in Javascript.


  • It was fun to investigate Java's NIO details, especially w.r.t. to efficient buffer management.
  • Java can be directly scripted via Rhino giving access to the full Java class library without extra code.
  • Scales nicely to very many clients (resources held per client are basically just the writebuffer and the current http parse state).
  • Based on the JVM (some people may consider it a disadvantage, though), so this integrates nicely with other Java libraries.
  • The code might be useful to somebody (maybe just to look at how the NIO stuff works).


  • See Thoughts-on-Performance and Benchmarks

  • SSL (use method described here and here)

  • Better Buffer abstraction. Currently Java ByteBuffers are used directly. This is awkward in some cases. Maybe this is as simple as a subclass with some helper methods, or maybe a Javascript decorator.

  • Test cases

  • Datagram sockets

  • More performance testing. Apache Bench is very limited.

  • Implement some real-life examples. (The canonical application seems to be a chat server :) )

  • Full FileSystem API

    • Currently one can use the Java API via Rhino. But that is awkward.
    • Only read and write streams are implemented in order to allow files to be served and read to and from network sockets.
  • Clean up the code

    • Some code is pretty adhoc at the moment.
    • Use Rhino built-in modules framework. The current version works, but it is pretty cobbled together (see comments in Global.java).
    • Javascript and Java classes are mixed (especially in the net module, although I am not 100% sure that is actually a problem since Java objects look exactly like Javascript objects to Javascript running in Rhino.)
  • Better name? Currently it's a combination of Rhino and Node (not very clever...)

  • Join forces with http://github.com/noonat/rhinode?