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
