Porting Tcl/Tk to Java
EKB
I just got this question e-mailed to me. I don't know the answer
(excepf for "Don't port to Java - keep it in Tcl/Tk!"). Does anyone
else?
"I searched around the web, but cannot find any definitive answer. My
question is ... I have alot of tcl/tkl code which was used in
developing a GUI some time ago. ...and my tcl/tkl is very rusty...
about 10 years or so. My customer is looking to port this code over to
Java ... do you know of any automated tools that can help do the
translation???"
Thanks!
Eric
Cameron Laird
.
.
Depending on how you feel, you say,
A. No. No way. What you're asking is ... well, no.
Not a good idea.
B. It's easy; use Jacl <URL: http://wiki.tcl.tk/jacl >.
Donal K. Fellows
> "I searched around the web, but cannot find any definitive answer. My
> question is ... I have alot of tcl/tkl code which was used in
> developing a GUI some time ago. ...and my tcl/tkl is very rusty...
> about 10 years or so. My customer is looking to port this code over to
> Java ... do you know of any automated tools that can help do the
> translation???"
As stated elsewhere, the answer can be either "Oooh, that's bad and
hard" or "Aaah, that's easy with Jacl". But I'm going to assume that the
real desire has to do with converting a Tcl/Tk GUI of about 10 years
vintage to Java.
That's a non-trivial task. If you're lucky and the GUI code was not
highly tuned, did not use [grid], and was limited in how it used [text]
and [canvas], you can fairly simply substitute Java Swing components for
Tk widgets. Most bits will go across fairly straight-forwardly, and all
you'll need to do is to create a LayoutManager that works like [pack].
But what about the cases which are excluded?
* If the GUI was heavily tuned, things will clunk horribly; tunings are
inevitably very bound to the specifics of a particular toolkit and
widget set.
* If the code used [grid] you're in trouble. The [grid] GM is very
complex and includes a linear equation solver among other things.
There is nothing like it on the Java platform (no GridBagLayout isn't
close!) and converting it is a lot of work.
* If the code makes advanced use of [text], you might be able to use
some of the advanced Java text editors. Or you might not; they
approach the basic problem in quite different ways. (If you really
want an RTF or HTML editor, Java is great for that.)
* If the code makes advanced use of [canvas], you are almost certainly
talking writing a whole new widget, err, JComponent.
Converting most Tcl scripts is easier, unless they make heavy use of
Tcl's event-driven API. While you can do that using NIO (google for more
info!) it's very clunky and low-level compared with Tcl's slick [after]
and [fileevent] commands; might as well be using C or C++.
Donal.
nyllet
Hi
I'm actually doing my thesis work in this area: a compile time
translator of Tcl code to Java. It will be released under GPL later
this year. However, I'm afraid it has some limitations that may make it
inapplicable for your purpose. It supports Tcl only, ie no Tk. Tcl
commands that would require threads or reflection in Java are not
implemented. Dynamical scoping, that is upvar and uplevel, are not
supported. Tcl scripts that exploits the weak typing of Tcl look clumsy
in Java, especially with generics. It targets Tcl 8.5. Furthermore, the
more the Tcl scripts rely on runtime properties, the harder it gets to
generate high quality Java code.
Still the forthcoming tool, named laugh, is useful as a translation aid
for many Tcl scripts, at least IMHO. If you want to become a beta
tester, please send me a mail
Regards
Martin
Neil Madden
In addition what others have mentioned (e.g., use of Jacl), I would also
point you at Swank (http://www.onemoonscientific.com/swank/index.html)
which is a port of Tk for Jacl/Java, which uses Swing. It may also be
worth looking at the TJC compiler that is part of the same project as
Jacl (http://tcljava.sf.net). This is a Tcl (Jacl) -> Java bytecode
compiler. IIRC, it may use Java sourcecode as an intermediate language.
While the generated source may be quite ugly, it may serve as a starting
point.
(Note for Tcl-URL! authors: TJC surely deserves to be product of the
week at some point, if it hasn't already been...)
-- Neil
EKB
who had sent me the e-mail, and also let her know about comp.lang.tcl.
Eric