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



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 partially satisfied
by the JNI interface.  The Perl inlineJava module and the Tcl tcljava
extension both use JNI to provide connectivity to the JVM.  Historically
there have been runtime issues with JNI because the extension only supports
the specific version of the JDK it's compiled against and the location of
the Java runtime on the installation server is picked up from environment
variables.  Problems occur when either the JDK is not at a supported level
or environment vararibles are not set properly.  The latest version of
TclBlend(Tcl + tcljava) overcomes this by embedding the JVM runtime in it's
install directory.  It ships with it's own JVM.

The Windows beta version is available here:

http://www.patrickfinnegan.com/

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.









-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
tcljava-dev mailing list
tcljava-dev@[...].net
https://lists.sourceforge.net/lists/listinfo/tcljava-dev