I posted similar questions to comp.lang.tcl before subscribing to this mailing list. I apologize if you have seen most of this already. I am experimenting with adding a scripting engine (either TCL or Python) inside a Java server program. I was able to load Jacl into my Java program. That worked fine except that not all TCL extensions are ported into Java. I'd like to run existing TCL scripts which uses packages that are not available in Jacl such "expect". Then there is TclBlend, which does a nice job of linking a native TCL interpreter with JVM. But TclBlend assumes that the TCL interpreter starts first, then it creates a JVM to run the Java code. That is the reverse of my setup, in which the JVM starts first, then loads the TCL interpreter. One suggestion is to use a separate TCL process that talks to the Java server through sockets. That is a viable option, but having two processes is not ideal for our customer. There can be issues with installation, startup and shutdown. I also looked at Alden Dima's Feather package at http://www.itl.nist.gov/div897/ctg/java/feather/. While it does let me start the TCL interpreter in my JVM, it is lacking the TCL calling Java aspect of TclBlend. As a result, it seems TclBlend is closest to my needs. As an experiment, I am trying to modify TclBlend 1.2.5 with Tcl/Tk 8.2.3 and JDK 1.2.2 on Windows NT 4. In my Java test code, I wrote a shell like the one in Jacl by doing: System.getRuntime().loadLibrary("tclblend"); Interp interp = new Interp(); while (true) { Notifier tclNotifier = interp.getNotifier(); while (true) { tclNotifier.doOneEvent(TCL.ALL_EVENTS); } } Commands are sent to the interpreter using another Java thread that read line of text on a socket. I submit my TCL commands by telneting to the socket using a normal telnet application. All this are adapted from the Jacl shell. In TclBlend, most of the native functions for the Java class methods expect some global structures to be setup to function properly. The structures are normally setup in the Tclblend_Init() function. However, if Tcl is to be loaded within a JVM, Tclblend_Init() is not called. I made a small modification to the Java_tcl_lang_Interp_create function to detect when the function is called and the globals are not yet initialized. If this happens, I initializes the globals using the existing "JavaSetupJava" function. Once this is done, the native TCL interpreter can be started by calling "new Interp()" in the JVM. However, there are issues related to how TclBlend tries to do synchronization using (*env)->MonitorEnter and (*env)->MonitorExit. These synchronization calls prevent multiple Java threads from using a single C interpreter. Before I tried to figure out how to solve this problem, I thought I would ask people who are more experienced with the TclBlend implementation the following questions. This will help me formulate a solution. 1. What is the java.NativeLock monitor protecting? Is TclBlend using the monitor to protect against multiple access to the C globals, access to the JVM, access to the TCL Interp instance, all? 2. Does having the globals and a global monitor mean that there is no benefit in using multiple TCL interp in Java in multiple threads? All calls are serialized by the monitor. 3. When the TCL Interp is idling such as in the native code of a tcl.lang.Notifier.doOneEvent(), TclBlend does not release the monitor. As a result, any other Java thread trying to access any of the tcl.lang.* native method will block due to the global monitor. Is this intended? Thanks for your help. -- Jiang Wu [EMAIL PROTECTED] BTW, the good news is that if I compile TclBlend without the synchronization calls, my test Java program is able to load the native TCL interpreter and execute TCL scripts in it. I tried out the gridDemo in the Jacl package and it worked. ---------------------------------------------------------------- The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe: send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
