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.
> >
<snip>
> >
> > 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.<init>(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 archive is available at http://www.mail-archive.com/tcljava@scriptics.com
