[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL
Here is the patch with the description of the problems solved in the patch.
Without the patch, my Java program causes an access violation when loading
TclBlend.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Jiang Wu [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 04, 2000 3:26 PM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] The Mythical TclBlend Patch
Sorry folks, I never send the TclBlend patch to this mailing list. I just
checked the Scriptics bug DB. My bug report is there now. It is number
4352. The report does not show the patch. I copied the bug report at the
end of this email. The patch is also attached to the email. The patch
allows one to write a Java based shell using native TCL through TclBlend. I
will post my modified Jacl shell later this week that you can use to try out
the patch.
-- Jiang Wu
[EMAIL PROTECTED]
==
TR#4352
Help | New Bug Report | Simple Search | Advanced Search | Product Summary |
Component Summary | Settings
Unable to start TclBlend from Java
TclBlend Java Interface
TclBlend Java Interface - TclBlend Java Interface
Found in Version: 1.2.6
Subject: Unable to start TclBlend from Java
Name:
Jiang Wu
ReproducibleScript:
The following Java program will crash.
-- Java program -
import tcl.lang.*;
public class Shell {
public static void main (String args[]) {
Interp interp = new Interp();
}
};
ObservedBehavior:
If one tries to start a native TCL
interpreter inside a Java process using TclBlend, the program produces an
access violation. Most of the TclBlend functions expect TclBlend_Init() to
be called first before "new Interp()" can function properly. However, if a
Java program tries to load TclBlend instead of a native TCL program trying
to load TclBlend, TclBlend_Init() is never called.
In particular, the above program will trigger an access violation in the
following location in /tcljava/src/native/javaInterp.c:
jlong JNICALL
Java_tcl_lang_Interp_create(
JNIEnv *env,/* Java environment. */
jobject interpObj) /* Handle to Interp object. */
{
jlong lvalue;
Tcl_Interp *interp;
JNIEnv *oldEnv;
JAVA_LOCK(); /* !!! this line triggers an access violation
!! */
/* ... stuff to create the native TCL interpreter ... */
JAVA_UNLOCK();
return lvalue;
}
DesiredBehavior:
One should be able to embed a native TCL
interpreter inside a Java program. One should be able to write a tclsh like
program in Java using TclBlend and the native TCL library. The embeded
native TCL interpreter in a Java program should behave the same a native TCL
interpreter running inside a C program.
Patch: Look in /home/bugs/tclblend under this bug number.
Patch files: java.h, javaCmd.c, javaInterp.c, Notifier.java
Comments
Comments on: Unable to start TclBlend from Java
The changes in the patch was tested using JDK 1.2.2,
Tcl 8.2.3 as well as the multi-threaded version of Tcl 8.2.3 on Windows NT
4. The changes fix the following 4 problems that prevented a native TCL
interpreter from being embeded inside a Java program.
1. In javaInterp.c, if TclBlend is started inside a JVM,
Java_tcl_lang_Interp_create() function uses an uninitialized global pointer,
java.NativeLock. The fix is to use a separate TCL mutex instead of the Java
mutex used in the JAVA_LOCK macro to protect TclBlend global data structures
used to store JVM information during TclBlend initialization. The change
touches java.h, javaCmd.h and javaInterp.c. TclBlend_Init() is also changed
to use the new mutex when it sets up the globals. The TCL mutex should only
be used if TclBlend is to be linked with the muti-threaded version of TCL.
The modified code uses the macro "TCL_THREADS" to determine whether to use
the TCL mutex or not. This macro should be define appropriately during the
compilation process. For non-threaded TCL, no mutex is used.
2. In the Java class Notifier, the method "hasEvent()" always returns true
if it is called within "serviceEvent()". This can happen if
"Notifier.doOneEvent()" triggers a "serviceEvent()" to eval "vwait" or
"update" TCL commands. When this senario happens, the program goes into a
busy infinite loop calling "hasEvent(), doOneEvent(), hasEvent(),
doOneEvent(), ...". "hasEvent()" is modified such that it skips all events
on the event list that is currently being processed at the moment
"hasEvent()" is invoked.
3. In the Java class Notifier, a synchronization deadlock can happen between
"serviceEvent()" and "queueEvent()". If the main thread for the interpreter
is executing a "vwait" inside a "serviceEvent()", it will block any other
thread from calling "queueEvent()" because the two methods are synchronized
on the Notifier instance object. The "vwait" command will ca
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL
> Hmm, this patch wouldn't happen to fix the following odd error I'm currently > chasing (below), would it? > > Exception in thread "main" java.lang.NullPointerException > at tcl.lang.Interp.create(Native Method) > at tcl.lang.Interp.(Interp.java:130) > at scriptmanager.ScriptManager.main(ScriptManager.java:24) That looks like one of them. Jiang could speak to that better than I. http://www.mail-archive.com/tcljava@scriptics.com/ > > I think you will find that in time, you > > will toss out all your other JNI code and just use Tcl Blend > > to do the "nasty JNI work". It is much easier to use Tcl or > > IncrTcl to interface with C or C++ code. > > Well, I doub't I'll toss the existing JNI code (read: I doub't I would get > *paid* to!) but certainly sounds like a plan for any future JNI territory. > Pulling one's own teeth would be more enjoyable than JNI ;) (well, maybe not > quite that bad) Thats funny, I was thinking that it would be more fun to poke myself in the eye with a pointy stick than write JNI code. > But can the Java-based Tcl extensions "turn around" and call methods and > access data of classes resident in the original Java VM instance (i.e. from > where the Tcl interpreter was started via Tcl Blend/JNI)? Yup, you can pass Java object handles around inside Tcl Objects. You can wrap and unwrap them in Java code, and then call any Java methods you want. See the ReflectObject docs for info on how to do this. http://dev.scriptics.com/man/java1.2/TclJavaLib/ReflectObject.htm Mo DeJong Red Hat Inc > In other words: I want a Java application to create a Tcl interpreter and > then have the Java extensions in that Tcl interpreter access objects/data in > the "parent" Java application. > > >From what I've read so far, I believe the answer is yes, but a sanity check > is always good insurance. > > john 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
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL
Wow, same day response, and no noise! (oops ;) Great email list. > -Original Message- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 24, 2000 5:13 PM > To: W. John Guineau > Cc: Jiang Wu; [EMAIL PROTECTED] > Subject: Re: [Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL > > > There are a bunch of posts on this Jacl vs Tcl Blend > thread so I will try to respond to points from each. > > > W. John Guineau Wrote: > > > We have a medium sized system (~250K lines of C++ and Java) that > > we want to graft Tcl scripting into. > > > > > > Am I asking for trouble by "going against the grain" on this? > > > The only problem you are going to run into is that Tcl Blend > currently needs a patch before it can be loaded directly into > Java. This patch will be merged into the CVS verison of > Tcl Blend very soon. There is some ongoing discussion about > how to do this best, so feel free to jump in with any > thought you might have on JAVA_LOCK or any other Tcl Blend > related issues. Hmm, this patch wouldn't happen to fix the following odd error I'm currently chasing (below), would it? = C:\JTCCSRoot\ui\Automation>set bld=debug C:\JTCCSRoot\ui\Automation>set path=c:\jdk1.3\jre\bin;c:\jdk1.3\jre\bin\classic;C:\tcl\tcl8.3.1\win\debug;c :\tcl\tcl8.3.1\lib\tclblend;.;C:\WINNT\system32;C:\WINNT; C:\JTCCSRoot\ui\Automation>set cp=C:\jdk1.3\jre\lib\rt.jar;.\classes;c:\tcl\tcl8.3.1\lib\tcljava.jar;c:\tcl \tcl8.3.1\lib\tclblend.jar C:\JTCCSRoot\ui\Automation>java -version java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C) Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode) C:\JTCCSRoot\ui\Automation>java -classpath C:\jdk1.3\jre\lib\rt.jar;.\classes;c: \tcl\tcl8.3.1\lib\tcljava.jar;c:\tcl\tcl8.3.1\lib\tclblend.jar scriptmanager.Scr iptManager Exception in thread "main" java.lang.NullPointerException at tcl.lang.Interp.create(Native Method) at tcl.lang.Interp.(Interp.java:130) at scriptmanager.ScriptManager.main(ScriptManager.java:24) EXP: tcl.lang.TclRuntimeError: could not find class java/lang/Object. Check that your path includes the directory where tclblend.dll resides. Try looking in the directories under the value of tcl_library, currently: Currently, the CLASSPATH environment variable is not set. = > I think you will find that in time, you > will toss out all your other JNI code and just use Tcl Blend > to do the "nasty JNI work". It is much easier to use Tcl or > IncrTcl to interface with C or C++ code. Well, I doub't I'll toss the existing JNI code (read: I doub't I would get *paid* to!) but certainly sounds like a plan for any future JNI territory. Pulling one's own teeth would be more enjoyable than JNI ;) (well, maybe not quite that bad) > > Jeff Sturm Wrote: > > > You can certainly write extensions this way, but why not use the java > > package, which is reflection based, instead? I find it easier to just > > invoke my methods directly from Tcl than to try to write a custom > > extension. > > W. John Guineau Wrote: > > > Well, if I use the Java package, then the Tcl code would not > > have access to > > the same run-time instance of the JVM that our code is running in, > right? > > (starting our Java code from Tcl is, unfortunetly, not an option.) > > Or am I missing something here? > > The java package is simply a library of utility commands that wrap > the java.lang.reflect package. You can use the java package in both > Jacl and Tcl Blend. Think of it this way, the java package is an API > that gives you the ability to dynamically invoke Java methods and > create Java objects from inside Tcl code. Both Jacl and Tcl Blend > provide an implementation of the Java package, but the code is > actually shared and does not "require" anything other than a JVM. > > So the answer is, you are both right. One could write all code > that interacts with the JVM using the java::* Tcl commands, or > you could write a Java extension that does the interaction. But can the Java-based Tcl extensions "turn around" and call methods and access data of classes resident in the original Java VM instance (i.e. from where the Tcl interpreter was started via Tcl Blend/JNI)? In other words: I want a Java application to create a Tcl interpreter and then have the Java extensions in that Tcl interpreter access objects/data in the "parent" Java application. >From what I've read so far, I believe the answer is yes, but a sanity check is always good insurance. john 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 archi
[Tcl Java] Re: [Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL
There are a bunch of posts on this Jacl vs Tcl Blend thread so I will try to respond to points from each. W. John Guineau Wrote: > We have a medium sized system (~250K lines of C++ and Java) that > we want to graft Tcl scripting into. > > The place where we would integrate scripting is all Java code. > > I see the recommended solution in this case is to use JACL, but for > performance reasons (and other factors) I would prefer to use Tcl > Blend. We already have a fairly significant JNI interface to > common C++ code, so I'm > quite familiar with JNI at this point (I see Tcl Blend also uses JNI.) > > My plan is to load the Tcl interpreter from within Java, and > then interact > with it from Java. We would then write Tcl extensions that > essentially wind > thier way back into our Java code, and therefore have access to all the > functionality we already have. We will also need to single step the > interpreter and view/modify variables from within the Java code. > > Am I asking for trouble by "going against the grain" on this? The only problem you are going to run into is that Tcl Blend currently needs a patch before it can be loaded directly into Java. This patch will be merged into the CVS verison of Tcl Blend very soon. There is some ongoing discussion about how to do this best, so feel free to jump in with any thought you might have on JAVA_LOCK or any other Tcl Blend related issues. I think you will find that in time, you will toss out all your other JNI code and just use Tcl Blend to do the "nasty JNI work". It is much easier to use Tcl or IncrTcl to interface with C or C++ code. Jeff Sturm Wrote: > You can certainly write extensions this way, but why not use the java > package, which is reflection based, instead? I find it easier to just > invoke my methods directly from Tcl than to try to write a custom > extension. W. John Guineau Wrote: > Well, if I use the Java package, then the Tcl code would not > have access to > the same run-time instance of the JVM that our code is running in, right? > (starting our Java code from Tcl is, unfortunetly, not an option.) > Or am I missing something here? The java package is simply a library of utility commands that wrap the java.lang.reflect package. You can use the java package in both Jacl and Tcl Blend. Think of it this way, the java package is an API that gives you the ability to dynamically invoke Java methods and create Java objects from inside Tcl code. Both Jacl and Tcl Blend provide an implementation of the Java package, but the code is actually shared and does not "require" anything other than a JVM. So the answer is, you are both right. One could write all code that interacts with the JVM using the java::* Tcl commands, or you could write a Java extension that does the interaction. There is a lot of flexibility, so the way you solve the problem is really up to you. I would suggest that using the java::* commands will be easier, as you can always prototype with the java::* commands and then move to a Java implementation of that prototype later. W. John Guineau wrote: > Ah, thank you for the document pointer! This looks to be the > motherload of Tcl Blend/JACL info! If there is any part of the current documentation that seems confusing or in need of a rewrite, please feel free to submit patches for the existing documentation. Docs are easier to patch than code :) Mo Dejong Red Hat Inc. 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
