Re: [tcljava-dev] tcljava-dev Digest, Vol 5, Issue 2

[Bruce J. <nm...@ma...>]

I agree to some extent with what you say, but personally I think that  
when the core of a language like Jacl catches up with the C version  
(and it is not that far now), that progress can potentially occur  
much faster.  There are so many APIs built-in to Java that  writing  
extensions is much faster than with C development, and once written  
they are cross-platform.  For example, I have scripted access to  
Oracle databases with just a few lines of Jacl calling the JDBC  
APIs.  I probably never would have set out to write a C interface to  
Oracle (like Oratcl etc.), but doing this with Jacl was a breeze.

Bruce



On Feb 17, 2007, at 3:37 PM, Patrick Finnegan wrote:

>
>>
>> (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
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev