tcljava-dev

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

[Fernando M. D. <fda...@uo...>]

Hi! All,

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.

Regards,

Fernando M. Dagostini

Brazil Technology Center - Finatel
E-mail: fd...@no...

=0A =0A__________________________________________________________________=
________=0AAcabe com aquelas janelinhas que pulam na sua tela.=0AAntiPop-=
up UOL - =C9 gr=E1tis!=0Ahttp://antipopup.uol.com.br/=0A

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

[Neil M. <ne...@cs...>]

Hello,

Some answers below

On 14 Dec 2004, at 19:34, Fernando M. Dagostini wrote:
   [...]
> 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?

I'm afraid not. Expect is a compiled extension for C-based Tcl. It=20
won't work with the pure-Java Jacl. You could use C Tcl/Expect as=20
before and use the TclBlend extension (part of the same project as=20
Jacl) which will allow you to load extensions written in Java into a=20
normal Tcl shell. This is essentially the reverse of the situation you=20=

describe - instead of embedding Jacl into your application, structure=20
the Java parts of your application into packages which can be loaded=20
into Tcl via TclBlend.

Another alternative is to try and port the parts of your app that use=20
Expect to use Java or pure-Tcl/Jacl scripts. Depending on what you use=20=

Expect for this could range from trivial to insanely=20
difficult/impossible. I don't know of any attempt to port Expect to=20
Java/Jacl, and I doubt it is even possible. =46rom what I gather, Expect=20=

does some very low-level magic, and it is quite likely that this sort=20
of control isn't available in Java.

>
> 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?

Jacl, like Tcl, is BSD-licensed, so you can do pretty much whatever you=20=

like with it. There should be a license.terms or similar in the=20
distribution which gives the full license details. It's quite short :-)

>
> 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.

Somebody else might be able to fill in any gaps I've left in the above.

Cheers,

-- Neil
Neil Madden (ne...@cs...)
PhD Student, Intelligent Agents Group,
School of Computer Science & IT,
University of Nottingham. NG8 1BB. UK.=

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

[Georgios P. <pet...@ya...>]

Why not loading a Tcl interp inside Java? I suppose you can write
a small C extension that does basic stuff (like creating an interp &
evaluating a string as code) and use swig to generate a JNI wrapper?

George

----- Original Message -----=20
From: "Neil Madden" <ne...@cs...>
To: <tcl...@li...>
Cc: "TclJavaUsers SourceForge" <tcl...@li...>
Sent: Tuesday, December 14, 2004 10:00 PM
Subject: Re: [tcljava-dev] JACL - Urgent help to make a design decision!


Hello,

Some answers below

On 14 Dec 2004, at 19:34, Fernando M. Dagostini wrote:
   [...]
> 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?

I'm afraid not. Expect is a compiled extension for C-based Tcl. It
won't work with the pure-Java Jacl. You could use C Tcl/Expect as
before and use the TclBlend extension (part of the same project as
Jacl) which will allow you to load extensions written in Java into a
normal Tcl shell. This is essentially the reverse of the situation you
describe - instead of embedding Jacl into your application, structure
the Java parts of your application into packages which can be loaded
into Tcl via TclBlend.

Another alternative is to try and port the parts of your app that use
Expect to use Java or pure-Tcl/Jacl scripts. Depending on what you use
Expect for this could range from trivial to insanely
difficult/impossible. I don't know of any attempt to port Expect to
Java/Jacl, and I doubt it is even possible. From what I gather, Expect
does some very low-level magic, and it is quite likely that this sort
of control isn't available in Java.

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

[Neil M. <ne...@cs...>]

On 14 Dec 2004, at 21:31, Georgios Petasis wrote:
> Why not loading a Tcl interp inside Java? I suppose you can write
> a small C extension that does basic stuff (like creating an interp &
> evaluating a string as code) and use swig to generate a JNI wrapper?

This is basically what TclBlend does, IIRC. Whether you load a Tcl 
interp into Java or load a JVM into Tcl you end up with the same 
situation - two interpreters communicating via some C glue.

Cheers,

Neil.

[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.

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

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

On Tue, 14 Dec 2004 14:17:09 -0700
D.J.Hagberg <dha...@mi...> wrote:

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

Just to clear up the confusion here. The "Tcl/Java" package is a Tcl
package of Tcl commands that is supported by both Jacl and Tcl Blend.
Tcl Blend is the JNI based layer that supports loading a Java VM into
a Tcl process or loading Tcl into an existing JVM. Jacl is a set of 100%
pure Java code that implements a Tcl interpreter.

> Jacl is also a bit dated, supporting only up to around Tcl 8.0 features.
> You definitely do not want to use 
> Jacl if a major part of your code base uses Expect.

It is true that Jacl can't load C based Tcl extensions like Expect. It is
a bit misleading to say that Jacl supports only Tcl 8.0 features.
Jacl supports most but not all the Tcl commands. The features Jacl
does not support typically can't be implemented using the existing Java API.

cheers
Mo DeJong

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