Re: [tcljava-dev] JACL - Urgent help to make a design decision!

[Mo D. <md...@un...>]

On Tue, 14 Dec 2004 17:34:51 -0200
"Fernando M. Dagostini" <fda...@uo...> wrote:

> We currently have a relatively large (12 Kloc) application 
> coded in Tcl/Tk/Expect or Expectix.
...
> Now, we are migrating parts of this larger system into a 
> newer one which is Java Client/Server based architecture _ 
> including Java/RMI for Client/Server communication.
...
> So, Jacl would be extremely useful in the sense that:
> 
> - Would save a  lot of effort w/o having to port the backend 
> code.
> - Clean design.
> - Would fit as a glove into the new Server system.

My take on this is that you will need to keep some of the
existing functionality in a C based Tcl shell. The kinds
of things that Expect does are not possible using the Java
API. Most of your application logic can be run inside your
Java environment using Jacl. As far as the GUI goes, you
might want to look into the Swank project, it implements
Tk style commands on top of Swing.

> 5 _ What are the licensing restrictions that may apply to 
> using Jacl in such a project?

No, see the license.terms file for the details.

> 6 _ Are there other implications that I should care about?

Well, Jacl code will run about 10x slower than Tcl code in
a C based interp because the C based interp has a built in
compiler. The big upside to using Jacl is that you can
easily do anything that can be done in Java and your
application will not crash.

I would read about Tcl Blend if I were you, but it seems
like this is a case where you want to move to an all Java
solution. The cool thing about Tcl Blend is that both
the Java interp and the Tcl interp exist in the same
process space, so communication is fast. The downside
is that loading Tcl Blend means you are no longer in
a 100% Java environment.

hope that helps
Mo DeJong