Trireme 0.8.0

This release fixes many compatibility issues with standard Node. The most significant is that we have switched
from the old "org.mozilla.rhino" to "io.apigee.rhino", and to the latest release of 1.7R5pre3. This has
a lot of fixes that improve compatibility with V8.

Trireme itself will continue to function on older versions of Rhino, but for best results, follow the
POM and use the one that is specified here...

• Issue 17 Support DSA signing and verification to complete the
  "crypto" module.
• Issue 24 Small tweaks to string encoding and decoding for
  a small performance gain.
• Issue 42 Implement "trimLeft" and "trimRight" on the String
  prototype even if they are not supported by the JavaScript runtime. This un-breaks the "jade" template
  engine.
• Issue 62 Make Java 6 filesystem code throw the same errors
  for symlinks and chmod as in Java 7.
• Issue 63 Allow process.argv to be replaced.
• Issue 64 Explicitly ignore the second argument to the global
  "escape()" function. This un-breaks several Amazon AWS modules.
• Issue 67 Support Error.captureStackTrace() and
  Error.prepareStackTrace() for better Node.js compatibility. This un-breaks the latest versions of Express
  3.x.
• Issue 68 Support string arguments to Cipher.update that
  have no encoding. This un-breaks the "httpntlm" module.
• Issue 69 Thanks to issue 67, update tests to Express 3.12.1
  to ensure that it keeps working.
• Issue 70 Don't use the "NetworkPolicy" in the Sandbox to control
  UDP ports. This makes it possible to send and receive UDP datagrams even if the NetworkPolicy does not
  allow listening on any port.
• Issue 71 Upgrade from org.mozilla.rhino version 1.7R4 to
  io.apigee.rhino version 1.7R5pre3. This adds a number of compatibility fixes that make more V8 code run
  unmodified inside Trireme.

Trireme 0.7.5

• Issue 56 Support Windows. This entails a bunch of work around
  path handling and file permissions handling.
• Issue 55 Fix process.platform to guess the platform and return
  a reasonable value.

With this release, by default Trireme will use the "os.name" system property to provide a value for the
"process.platform" property. Supported values are:

• darwin
• freebsd
• linux
• sunos
• win32

In addition, if a "Sandbox" is configured on the NodeEnvironment and the "setHideOSDetails" function is called, then "process.platform" will instead return "java" as it did in previous releases.

This is an important change for the Windows platform as many parts of Node.js and third-party modules try to do things differently on Windows.

Trireme 0.7.4

• Issue 54 Properly raise an 'error' event if
  child_process.spawn() is blocked due to the Sandbox being enabled.
• Issue 53 Add the new trireme-xslt module which uses native
  Java XSLST processing and supports multiple threads. Also, create a compatible version of the
  "node_xslt" module so that it may be used in Trireme as well without requiring libxml.

Trireme 0.7.3

• Issue 51 Java 6 only: mkdir should return ENOENT on non-existent
  parent directories.
• Fix ipc in child_process module so that it works.

With this fix, a Node.js app running in Trireme can "fork" a sub-process
and communicate via the IPC pipe using "send" on the child process and on the "process" object, as described
in the docs for the "child_process" module.

Handles are not yet supported, which means that a parent cannot send a TCP socket to a child and expect it to process it.

Note that unlike regular Node.js, child scripts spawned using "fork" run inside the same JVM as the parent,
but with a totally different script context and in a separate thread. "IPC" communication happens using a
concurrent queue. Communication between parent and child via this mechanism should be very fast.

Trireme 0.7.2

Trireme 0.7.2

28-Mar-2014:

• Issue 47 When the executeModule() function is used to run
  a script (instead of the more typical "execute()"), process.argv was not being generated in a consistent
  way.
• Issue 49 HTTP responses that included an extra space at the
  end of the status line (such as "HTTP/1.1 413 ") were resulting in a parsing error.

Trireme 0.7.1

Trireme 0.7.1

Released 18-Mar-2014

The biggest change in this release is that you must include at least two Jar files in order for Trireme to work:

• trireme-core
• trireme-node10src

The reason is that we are separating the Node.js-specific JavaScript code from the generic runtime in Java.
That way, in the future we may be able to support multiple versions of Node.js in the same runtime.

In the past, you only had to declare "trireme-core" in pom.xml and Maven will pick up everything. Now, you need
to include both packages listed above, or you will see the error: "No available Node.js implementation".

• Separate version-specific JavaScript code from the core runtime. This lays the groundwork for supporting
  multiple versions of Node.js in the same instance of Trireme by using the same low-level support in Java
  across all versions, and running different versions of the Node.js JavaScript code.
• Issue 32 Add a mechanism to cache compiled JavaScript
  classes. This reduces memory usage and startup time in servers that host many Node.js scripts in a single
  Trireme environment. The cache works by creating a SHA-256 hash of the source and using that as the key.
• Issue 41 Relative symbolic links were being mangled by the
  code that implements the "sandbox" functionality. The result was that NPM didn't run. Now NPM can run on Trireme.
• Issue 45 Add an "extra class shutter" to Sandbox that allows
  implementors to expand the list of Java classes that may be called directly from Trireme. By default, only
  a few classes are supported, which means that Node.js code cannot normally invoke Java code directly unless
  additional classes are whitelisted using this mechanism.

Files Below

"trireme.0.7.1.jar" is a stand-alone jar, to be run with "java -jar" just like "node".
The other jars are individual modules -- see the README or get them from Maven Central as usual.