Backgroundnsjava was originally developed as part of the opeancs 3.2.x porting effort, and it was quite simple in that it only supported the calling of Java Static methods from Tcl. The Aolserver DB api was also exposed to user-defined java classes through a set of JNI classses. This worked well enough for its intended purpose of porting the Webmail package which made extensive use of Java inside of Oracle.
Extensive testing with various jdk's revealed the flakiness to which Don and Michael have alluded. I had stablity problems with most vendors except for Blackdown's 1.1.8 on Redhat and Sun's 1.1.8 jdk on Solaris. In addition, it was nearly impossible to get nsjava to build on any other linux distro other than Redhat. This seemed to be due to pthread library compatiblity problems between the pre-build jdk distro's and the various pthread library versions distrubuted with various linux vendors OS's.
After the openacs 3.2.x porting effort was complete, I spent some time integrating TclBlend with nsjava, and I released this as an Aolserver module called nsjavablend. This module provided all of the features of TclBlend within Aolserver, but it suffered from several short-comings of the TclBlend design. TclBlend was designed as single-threaded app, so there were several design conflicts when it came to converting it to a multi-threaded app. Extensive testing of nsjavablend revealed several memory leaks, which were quite difficult to track down. It seemed that the reference counting of java objects wasn't completely correct.
In addition, cleanup of the Tcl interpreter would trigger a call to the JVM after thread-detach which would crash the server. I found a work-around for this problem, but it involved fooling the TLS cleanup routine, so that thread detach wasn't done until after the interpreter had been destroyed.
Once the Openacs-4 porting effort started, I found little time to work on or support nsjava, so I put it aside and I didn't bother to much with trying to develop it further.
Once the Openacs-4 porting effort was completed , I started thinking about how to fix nsjava(blend). Since I couldn't find a simple way to track the reference counts of java objects in TclBlend, I started from scratch and reimplemented the TclBlend core functions using nsjava as a starting point. This worked well and to save development time I re-used TclBlend code whenver I could. The end result is that I have reimplemented a sub-set of TclBlend's functionality in nsjava, and I no longer have the reference counting and thread-detach problems that I had when I integrated TclBlend with nsjava.
Current Statensjava is currently at version 1.0.4, and it supports the following sub-set of TclBlend's commands:
: Allocate Java objects.
nsjava::call : Invoke static Java methods.
nsjava::field : Get and set Java field values.
nsjava::instanceof : Determine if an object is an instance of a Class.
nsjava::info : Introspect Java objects and classes.
nsjava::null : Get a handle to the null Java reference.
nsjava::isnull : Test a handle to see if refers to null.
nsjava::lock : Lock a Java object so that it can not be garbage collected.
nsjava::unlock : Unlock a Java object that had been locked previously.
nsjava::throw : Throw a Java exception.
nsjava::try : Catch a Java exception.
nsjava::cast : Cast a Java object from one type to another.
java::import : Import a Java class name so that fully qualified name need not be used.
javaObj : Invoke instance methods on an object.
javaArrayObj : Invoke methods on an array object.
In addition, I have ported the TclBlend test harness to work with nsjava, and I have ported almost 600 individual tests which exercise almost all aspects of the nsjava implementation.
LimitationsThe nsjava module is currently limited to one tcl interpreter per aolserver thread. Tclblend users are used to creating additional interpreters, but doing so in nsjava/aolserver will cause unpredictable results, and it will probably crash the server. Using multiple Tcl interpreters within a single thread is not a common practice in Aolserver, so I don't see this as a big limitation.
db queries in user-defined java methods are not yet supported in the startup thread. This is due to Aolserver blocking signals in the startup thread, which makes it necessary to run the JVM in a separate thread. I have started on a work-around to mitigate this problem, and it will be available in the next release. Once this change is made, nsjava will pretty much be feature complete. nsjava does not affect the normal operation of Aolserver, so it is still possible to perform db queries from Tcl in the startup thread.
- Add db support for java methods in startup thread (in-progress)
- Compatiblity testing - ensure that nsjava builds and runs on same platforms that are supported by Aolserver. (currently builds and runs on various jdks for Redhat Linux and Solaris). I need access to other platforms to complete this or volunteers for testing would also help.
- Load testing
- Extend test harness for more comprehensive testing coverage. (Done)
- Add support for passing binary data to/from java via Tcl
- Add db support for oracle
- Implement jdbc interface on top of aolserver api? Not sure if this is important. Might be important to people coming from the java world.
All-in-all, I'm pretty happy with the progress I've made so far. I find that it is quite easy to write nsjava scripts in Tcl, and it makes it quite easy to integrate available java libraries with Aolserver. The discussions on dotLRN have gotten me thinking on how to take advantage of all of the Apache-java work that has already been completed, where they have already implemnted most of the web-services componenets that we need for extending dotLRN. Things like XML-RPC, SOAP, WSDL are already available for Apache, and I'm guessing that it wouldn't be too difficult to make them work on Aolserver/nsjava.
More information can be found at the nsjava project page.