Having one command that does two totally unrelated things seems
like a bad design if you ask me. It might be cleaner to define
a command to invoke the static method and another one to actually
do the shorter cast operation. What if you used something like this?
set s [java::new String "I am a Jav
Done - the URL is
ftp://ftp.scriptics.com/pub/tcl/java/tclBlend125-jdk11.zip
^^^
>>>Scott Redman said:
> I managed to somehow package the JDK1.2 version of TclBlend 1.2.5
> for Windows in the JDK1.1 zip file.
>
> So, everyone having problems w
I managed to somehow package the JDK1.2 version of TclBlend 1.2.5
for Windows in the JDK1.1 zip file.
So, everyone having problems with the JDK1.1 version should soon
have relief. I've re-zipped the file, and I will have Brent Welch
update the ftp site today. I will send out email when that is
On Tue, Nov 16, 1999 at 09:25:22AM -0600, Moses DeJong wrote:
>
> Well, Jacl 1.2.5 already includes a java::import command
> so your java::import command would conflict.
Sorry, I didn't make this clear -- this is implemented as an
extra option for the existing java::import. The current behaviou
On Tue, 16 Nov 1999, Thomas Down wrote:
> I've written a simple patch for JaCL (should also work with
> TclBlend, I guess) which allows you to create a new Tcl command
> for each java class which you import. This provides an easy
> approach to casting, e.g.:
>
> package require java
Well, Ja
I've been using JaCL for some time, largely for running simple
scripts which generate reports from biological databases. Looking
through my code, I find that I'm using rather a large number of
java::call commands, and also some java::cast.
I've written a simple patch for JaCL (should also work w
