I know zero about designing/implementing dynamic languages but I've wanted to write one for a while. Without a doubt, the JVM is the place to be; All the work that's been done to provide abstraction layers over anything from databases through guis, there's no reason to avoid it.

I was thinking of doing some work with Jacl, the Java port of the TCL interpreter to get a feel for how it's doing and performance as compared to the C version and testing extending it to work with things like servlets and maybe one of the popular gui toolkits...

Wishful thinking of course, but its fun checking out the code, setting up the project and pretending like I'll have the time to actually do anything with it ;)

I'm glad that Sun is willing to look at enhancing the JVM to support languages other than Java; whether they are dynamic or not, I think that shift in position is in itself important.

The "problems" of implementing dynamic languages on the JVM also include that many of these languages use code in binary form (written in C, C++ or other) to extend themselves. That's one hoop we're not going to get over with this JSR. It will continue to be a problem for languages with a large existing codebase in their non-JVM version which are trying to port over.

What I'd like to see is Sun/the community find a way to get more of these language implementors to talk with each other in public forums. I wonder, for example, why Pnuts shows good performance numbers on published benchmarks. What are they doing the others can learn from? I wonder if there is more implementors could learn from each other, and if there are certain parts of their lexers/parsers/libraries which could be shared to speed up (or improve) language development. Sometimes I wonder how much the wheel has been re-invented across all the many languages already on the JVM.

Will be interesting to see what comes of the JSR.

Patrick

The summary is misleading Java SE 6 is no longer only about the Java language: SE 6 can be used to execute dynamic scripting language code as well. According to Danny Coward, Sun's Java SE platform lead, scripting language support is merely the first step in turning the JVM into the best possible execution platform for any dynamic language. Artima spoke with Coward about his new JSR 292, Supporting Dynamically Typed Languages on the Java Platform.

JSR 292 will initially be delivered in Java SE 7 - the summary reads as though it's delivered in Java SE 6

The initial specification lead of jsr 292 Gilad Bracha has left Sun recently. In his blog (http://blogs.sun.com/gbracha/) he says "but I know how long and painful a process it is to get any such initiative to fruition". I thought that meant the end of JSR 292, and I'm glad it seems this jsr is still alive.

The article makes it appear as if this has never done before, but in reality the Bean Scripting Framework (BSF) has delivered many JSR-223 features for years. Granted, it wasn't shipped with the JRE, and supports fewer languages (still a dozen, though), but to not even mention it seems disingenious.

Another thing would be to support other static languages that target JVM.

For instance, Boo is a really nice language that targets .NET platform. How about JBoo? :)

JVM doesn't provide a way to have unboxed integers together with pointers in the same type. This means that all dynamically typed integers must be heap allocated.

Another issue, independent from dynamic typing, is the lack of a sensible way to implement tail call optimization.

These two reasons are enough to make JVM unsuitable for hosting my language. This hasn't changed since JVM's beginning.

(.NET is almost as bad. It allows easy TCO in theory, but it's much slower than it needs to be.)

We noticed over the last couple of years that the Java developer community—unlike the .NET developer community—was starting to experiment with dynamic languages.

Oops, IronPython 1.0 is out with Visual Studio integration. Microsoft hired the Ruby-to-CLR bridge guy before Sun hired the JRuby guys, and there's an experimental RubyCLR compiler that actually compiles down to CLR bytecode. I guess someone in the .NET community was interested.

But I think the dynamic hype is just that - hype from the blogosphere. Sun needs something like Boo (on the CLR), a nice wrist-friendly, statically-type inferred language, with an easy-on-the-eyes syntax.

Or maybe Sun could fund Scala. Microsoft goes forward with adding functional language features in C# 3.0 and Sun gets caught up in the RoR hype. Or why doesn't Sun fund something like Groovy, which was specifically designed for the JVM, instead of trying to kludge in Ruby.

I've been a Groovy committer for about three years now so I have a little experience in implementing a dynamic language on the JVM. My views are my own and do not neccessarily represent the other project members' views.

Sun has come very late to this party. I think it's particularly unfortunate that they have proposed a solution without apparently trying to understand the problem fully. We have certainly had no contact with Sun prior to the announcement of JSR 292 (with the exception of a dynamic languages "summit" which Sun sponsored a couple of years ago - I don't think any of the people who were at the summit are involved in dynamic languages on the JVM any more). We have a member on the expert group but the group does not seem to do a great deal at the moment. In any case it appears to be aimed at refining the semantics of invokednamic rather than deciding how to improve the support of dynamic language on the JVM (doing the first may not achieve the second).

Dispatching method calls is certainly a big problem in the efficient implementation of the language but it's not the biggest (efficiently associating metadata with each class is probably our biggest problem). I don't really recognise Danny's description of the brittleness of synthetic types - we do dynamic code generation for parts of our MetaClasses (which is what I think he means by "synthetic types") and so changing a Java class is handled seamlessly. Of course, other implementers may have this problem.

It's really distressing to hear senior technical people talking about "interpreters" (JRuby is currently an interpreter but that's changing, Jython and Groovy are not and never have been interpreted - many other dynamic languages are compiled to bytecode too). Remember the old days when the clueless claimed long and loud that Java was "slow" because it was "interpreted", remember how annoying that was.....
The use of "Scripting language" and "dynamic language" as synonyms is equally distressing.

Now it may be that Sun have sought input far and wide from practitioners in this field and for some good reason have not asked any of the Groovy implementers what problems they have and what solutions they have found. It may also be that Sun's old NIH habit has reasserted itself and that a bunch of fearsomely bright guys have had a couple of meetings in a Sun conference room and decided that they understand the problem completely and are ready to give an eager world the perfect solution they have been waiting for. Take your pick.

I do think it's likely that JSR 292 will not actually make it harder for us to implement dynamic languages on the JVM so there is, at least, a bright side to this.

This dynamic language support is quite interesting. But, I am more interested knowing whether Java support Dynamic Language Development?

For ex., something like;

if (MyClass instanceof "<class / interface Name>") {
// do something.
} else {
// do something else.
}

Where I can supply the "<class/Interface Name>" dynamically at runtime is that at all possible? Is that what this Dynamic Language Support of Java 6.0 does? This will be a real cool feature.

In other languages (including scripting) you can actually change/write a new program behaviour using dynamic development.

For eg., Using eval you can call a function or validate a string to an object in Java Script.

You can do similar or more things in PERL, PHP an so on.

Java didn't support any of the above feature until Java 5.0 as far as I know. Can I do the above in Java 6.0?

Thanks.