Forum OpenACS Development: Java in 4.0

Collapse
Posted by Ben Adida on
There's Java in 4.0. Some of it is there for LDAP authentication,
some of it is for content. Not all of it needs to stay Java, but some
of it might as well (especially the LDAP stuf).

Thus, we should pursue the nsjava option very seriously at this
point. The most important thing is to allow full Java API access
from Tcl. The next important step will be to make sure the
Java/DB API of nsjava works well.

The idea behind this is that adding Java processing directly to
the DB is not the best solution, given that the DB is already the
performance bottleneck. We should discuss this, though, to
make sure that we think of all the issues involved in adding Java
to the equation.

Collapse
2: Response to Java in 4.0 (response to 1)
Posted by Dan Wickstrom on
Ben,

Could you elaborate on what you mean by "full Java API access from Tcl"?

Collapse
3: Response to Java in 4.0 (response to 1)
Posted by Ben Adida on
By "full Java API" I mean the ability to create Java objects from Tcl, and to call methods on them. Something roughly like:

set java_object [ns_java instantiate JavaClass]
set result [ns_java methodCall $java_object  methodName 
methodArg1 methodArg2]
Collapse
4: Response to Java in 4.0 (response to 1)
Posted by Dan Wickstrom on
If this is the only java scripting functionality that is required for acs 4.0, then it would be relatively easy to implement in nsjava. I have however been lately working on merging nsjava and tclblend together, which would give complete access to the java api from tcl. I think that most of the tclblend tcl api commands could be made to work in nsjava/aolserver. The following is a list of the tclblend tcl api:
tcl commanddescription
java::new : Allocate Java objects.
java::call : Invoke static Java methods.
java::field : Get and set Java field values.
java::instanceof : Determine if an object is an instance of a Class.
java::prop : Manipulate Java Bean properties.
java::bind : Bind a Tcl script to a Java event.
java::event : Query event objects in a Java event callback.
java::info : Introspect Java objects and classes.
java::null : Get a handle to the null Java reference.
java::isnull : Test a handle to see if refers to null.
java::lock : Lock a Java object so that it can not be garbage collected.
java::unlock : Unlock a Java object that had been locked previously.
java::autolock : Manage automatic locking of Java references during interactive sessions.
java::load : Load a Tcl extension defined in a Java class.
java::defineclass : Convert binary .class data into a java.lang.Class object.
java::getinterp : Get a handle to the tcl.lang.Interp object.
java::throw : Throw a Java exception.
java::try : Catch a Java exception.
java::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.

nsjava already supports the equivalent of the tclblend java::call command and what Ben has proposed corresponds to the tclblend java::new and the javaObj api calls. I still have quite a bit of work on the tclblend/nsjava merge, and I don't think that it would be practical for me to finish the work in time for the acs 4.0 porting effort. I would however like people who are looking at the new acs 4.0 code to let me know if they see instances in the code where it would be necessary to add code to nsjava to support additional java api functionality that corresponds to what I have illustrated with the tclblend api description.

Collapse
5: Response to Java in 4.0 (response to 1)
Posted by good bye on
The idea behind this is that adding Java processing directly to the DB is not the best solution, given that the DB is already the performance bottleneck. We should discuss this, though, to make sure that we think of all the issues involved in adding Java to the equation.

Adding java to the DB would only cause more of a performance bottleneck if the jvm running inside postgres was indeed slower than an external jvm. Is this necessarily going to be the case? It would seem that a JVM inside of postgres would be a much cleaner design than a tcl interpreter spawning a java process in a thread.

Collapse
6: Response to Java in 4.0 (response to 1)
Posted by Ben Adida on
Rolf, that's not quite the case. If you separate your AOLservers
into multiple boxes, with Postgres on one big back-end box,
having the Java processing at the AOLserver layer makes a lot of
sense.

Most importantly, we're definitely not talking about spawning a
java process. We're talking about nsjava, which is a running JVM
inside an AOLserver module, that can be directly accessed from
Tcl, inside the same process.