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

[D.J.Hagberg <dha...@mi...>]

It sounds to me like what you really want is the TclJava package, not=20
Jacl.

TclJava is a "normal" extension to the C-based Tcl, extending it with a=20=

set of java::* commands like java::new, java::call, etc.  It can be=20
used from Tcl to make calls on classes in Java libraries, e.g. to use=20
JDBC drivers from Tcl (or make RMI calls in your example below), mixed=20=

in with calls to other C-based Tcl extensions such Expect.

Jacl is a complete re-implementation of Tcl in Java.  It cannot use=20
C-based extensions such as Expect.  It is also a bit dated, supporting=20=

only up to around Tcl 8.0 features.  You definitely do not want to use=20=

Jacl if a major part of your code base uses Expect.

That said, the Tcl-level (calling Java from Tcl) commands and=20
Java-level library (calling Tcl from Java) is nearly identical between=20=

the two packages, thus the confusion, perhaps.

That said, you might consider *not* doing a direct binding between the=20=

Tcl back-end and the Java front-end.  You could run your Tcl back-end=20
in a separate process, exposing its set of functionality as a set of=20
SOAP interfaces (see the TclSOAP package), or a simple line-oriented=20
command socket.  Then create a small Java library that makes calls on=20
your Tcl back-end process, either over SOAP or the simple line-oriented=20=

command socket.

                             -=3D- D. J.

On Dec 14, 2004, at 12:34 PM, Fernando M. Dagostini wrote:
> I am about to make a high level design decision for a project
> in the company I work for.
>
> --- Brief:
>
> We currently have a relatively large (12 Kloc) application
> coded in Tcl/Tk/Expect or Expectix. The application provides
> a whole bunch of functionalities to the user via Tk widgets
> and accesses system resources in the backend including
> Socket, File Handling, Spawning external executables, etc.
>
> All this is part of a larger system in the Wireless CDMA
> network management.
>
> Then environment is Sun Solaris.
>
> --- Objective:
>
> Now, we are migrating parts of this larger system into a
> newer one which is Java Client/Server based architecture =96
> including Java/RMI for Client/Server communication.
>
> We have estimated that the application as is today is
> balanced between:
>
> - 1.5 Kloc of Tk front end code (GUI)
> - 10.5 Kloc of Tcl/Expect back end code
>
> in a single script file =96 yes, total of 12 Kloc in a single
> program file!...
>
> Needless to say that our first thought was to port the GUI
> part of the application to the Java Client and reuse the
> backend part entirely, with little adjustments, in the
> Server. To accomplish this we would like to implement a
> collection of simple Java/RMI classes =96 basically to map
> remote client calls directly into Tcl procedures - and glue
> them to via Jacl.
>
> 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.
>
> --- Questions/Problems:
>
> 1 =96 Is this really an approach that Jacl can support.
>
> 2 =96 I=92ve noticed that the =93package=94 command =93=85completely
> implemented in Jacl.=94  as stated in the DIFFS.TXT file so, I
> am assuming that I can load the Expect extension by issuing
> the command =93package require Expect=94, is this correct?
>
> 3 =96 I=92ve gone through all the commands mentioned in the
> DIFFS.TXT and found that, at least based on what is stated
> there, I can get around those commands listed in =93What
> Partially Works=94 with minor changes in the Tcl code.
>
> 4 - I=92ve tried step 2 above in a Jacl shell command line but
> it didn=92t work. If it should work what am I doing wrong?
>
> 5 =96 What are the licensing restrictions that may apply to
> using Jacl in such a project?
>
> 6 =96 Are there other implications that I should care about?
>
> Sorry for the long posting - we are really interested in
> using Jacl but the project is large enough to take high risks
> at this point.
>
> We appreciate your opinions/suggestions.