| Patrick Finnegan 2007-02-21, 7:15 pm |
| I think the future of dynamic languages in the JVM really depends on
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.
|