Sun Microsystems RFC - Tcl on the JVM.
Patrick Finnegan
Charles Oliver Nutter of Sun Microsystems has requested feedback on
the future of dynamic languages on the JVM. The Tcljava-dev mailing
list has limited distribution so I have posted his request here.
http://sourceforge.net/mailarchive/forum.php?thread_id=31673126&forum_id=3849
Dynamic Languages on the JVM: The Future
(Hi there Tcl enthusiasts and Jacl devs! This is kind of a form
letter,
but I'm serious about getting this event together with devs from
multiple languages. I'd love to hear your thoughts on such an event
and
see if you'd be interested in attending.)
Hello all!
I am attempting to organize an outside event for JavaOne this year
entitled "Dynamic Languages on the JVM: The Future". It is my intent
to
have as many alternative (dynamic) language implementers together in
the
same place as well as Java and JVM developers and specifiers. This
would
be our opportunity to talk about areas that have caused us trouble,
features we'd like to see in Java or the JVM (or features we'd like to
remove) and other related topics. I really want to break down the
boundaries between the language implementations/implementers so we can
cooperatively work toward making the JVM a more dynlang-friendly
platform.
Ideally we'd have as many of your core team as possible (or others, as
you see fit) in attendance. I'll be there, as will at least Tom Enebo
and Ola Bini of the JRuby team. I'm also reaching out to other
language
teams in hopes of having a really good cross-language discussion.
The event would likely be hosted at a nearby hotel, bar, or
restaurant.
I'd like it to be pretty informal, but somewhere we can actually talk.
It would help my cause to get this event organized (and funded) if I
could get a vote of confidence from likely attendees. Many high-level
folks at Sun have already voiced their approval, and I think this is
an
excellent opportunity for us to show that real cooperation between the
dynlang impls is possible and that it would be productive.
Please feel free to reply on this list (assuming the owners don't
mind)
or in private if you have questions or to voice your opinion. This is
going to be a big year for dynlangs on the JVM, and we need to make
sure
things keep moving in the right direction.
--
Charles Oliver Nutter
JRuby Core Developer
Senior Staff Engineer
Sun Microsystems, Inc
Donal K. Fellows
> (Hi there Tcl enthusiasts and Jacl devs! This is kind of a form letter,
> but I'm serious about getting this event together with devs from
> multiple languages. I'd love to hear your thoughts on such an event and
> see if you'd be interested in attending.)
I'd like to really encourage someone to participate in this - the non-
mainline forms of Tcl implementation are always interesting - but I
cannot do so myself due to JavaOne being far too close to other events
that I'm committed to, alas. (Perhaps someone can go and then provide
F2F feedback to the rest of us in a BoF at the Tcl conference? That'd
be really cool, and I'm sure ethanol can be arranged to help
then. :-))
But scheduling issues aside, there's some interesting issues here
anyway. One of the key ones is that many dynamic languages (Tcl
definitely included) use a value model that has _objects_ capable of
changing their type/class dynamically (requiring that the classes that
are switched between satisfy some sort of advanced constraint is
reasonable). I think actions to support this sort of thing would be
valuable.
In terms of GUI stuff, I'd say that Tk's most valuable reusable things
are the geometry manager algorithms. (There are other great bits of Tk
too, but the other parts are harder to work with without Tk itself
there; the GMs are usable on their own.) As such, it might be a
reasonable idea for someone to port the 8.5 geometry managers and get
them into the core Java set; in particular, [grid] is massively beyond
anything in Swing, the AWT or even the SWT. (This isn't JVM work, but
it is something worth reusing in many other places.)
Donal Fellows (with TCT/Tcl Core Maintainer/Tcl2007PC hats on).
Patrick Finnegan
whether
non Java developers find Java based deployment of their favourite
dynamic
language an attractive proposition.
There are two approaches to integrating C based dynamic languages with
the
JVM. One is to rewrite the underlying implementation in Java instead
of C
so that the language runs within the JVM. The dynamic language
commands
and syntax are interpreted into Java rather then C. The other is Java
Native Interface. The dynamic language loads a JVM into the C runtime
and
makes calls to JAVA using JNI pointers.
Running dynamic languages within the JVM is attractive to Java
developers
who wish to develop hybrid or mixed language applications because it
allows
development within a single IDE and deployment to a single runtime
environment. However it has some major drawbacks. Most of the
dynamic
languages have a small core command set and are dependent on external
packages or extensions to provide the rich set of features required
for
enteprise development. In most cases it's only the core that has been
ported to Java and developers soon find that they have to make
extensive
use of of the java class libraries to provide features that are
missing
from the embedded version of the dynamic language. No ldap support in
JACL.
No smtpd support in Jython. No Rails support in JRuby(Current
version).
That makes it difficult if not impossible to port a dynamic language
application written for a C runtime environment directly to a Java
runtime
environment without an extensive rewrite. Then there is the catch up
issue.
New features in dynamic languages need to be back ported to Java.
This is a
huge overhead that could cripple application development budgets.
Most
Java programmers would rather use a native Java dynamic language like
Groovey rather than jump on the backport treadmill.
Non Java developers already have a complete toolset for dynamic
language
development and the most popular dynamic languages are certified to
run on
most operating platforms. So they already have write once run
anywhere
capability. However there is a demand for an interoperability layer
between
dynamic languages and JAVA that allows the C based runtime call Java
class
libraries and interact with Java applications. This is mostly
satisfied
by the JNI interface. The Perl inlineJava module and the Tcl tcljava
extension both use JNI to provide connectivity to the JVM.
I suppose the holy grail for dynamic languages and Java is really
reverse
JNI i.e a C runtime environment inside the JVM that would allow JAVA
to
support any C based interpreted language natively without the need for
expensive rewrites in Java. Java needs something conceptually similar
to
the Common Language Runtime engine in the .NET framework that would
allow
transparent execution of C processes under Java. Application
portability
across Java and C runtime environments is the best way to attract
dynamic
language developers to Java.