Wednesday August 27, 2008
Firing up the engines for multiple languages
Filed under: javafx javase7
Have you seen the latest update from John on our efforts to make the
JVM run multiple
languages ? (I'm in a staff meeting writing this, but don't tell
anyone :) ).From one to many languages
For those of you who would like a little context around International Invokedynamic Day, for the last few years we've been on a path towards first class support for other languages on the JVM. No small feat this, since the Java Platform was originally designed with one language in mind. Now, we still believe that Java is the best language for robust, long lived code. But we know that developers like to mix in other languages that for special reasons: for particular applications, for particular styles of development. Just as important, we've spent 13 years creating an incredibly scalable and high performing runtime across a variety of operating systems. So for developers who create applications with other languages (and we hope there will be many who like JavaFX Script), we figure they would like to run those apps on the best runtime around.
So, as a matter of fact, do the creators of the engines for other languages like Ruby, Python, Groovy, Scala - they started creating the engines to run on the Java Platform.
Lining up the engines
So for Java SE 6, we provided a framework by which those interpreters could plug easily into the Java Platform. And the developer APIs by which the code from those other languages can be asked to execute. We even bundled a JavaScript engine into our own JDK. At the same time, more and more developers created the engines to run other languages on the Java platform.
Firing up the engines
Now, many of the languages that are attracting the buzz that have been invented since the Java language have a feature in common with each other, but not with Java: they are dynamically rather than statically typed. So the types of the variables, method parameters, return variables and so on are not known at development time, unlike in Java where you are required to declare them. All very nice for rapid prototyping and a more informal style of programming, but a big problem for compiling it down to the Java bytecode because the Java bytecode needs that type information filled out. So engines for dynamic languages have to create artificial interfaces or classes just to do the form filling. Making them brittle, difficult to maintain and slower than they could be. But not if we modify the bytecode to remove the need to fill out all the type information.
So back to the update: John has prototyped support for the modified bytecode in the HotSpot JVM !
What this means is that implementors of dynamic language engines are now free to try this out and prove the theory. I'm predicting that Charlie will be one of the first with his JRuby project, but the race is on.
Some of the newer languages have other features in common, like closures for example. There may well be other features we will build into the Java runtime to support such features better like tail call recursions, continuations and lightweight method handles. But we'll see how it goes with new bytecode and get some real data and decide how much further we need to go.
If, say, Ruby, Python and Scala run faster on the JVM than anywhere else, we may just be done. For now :)
Posted by dannycoward ( Aug 27 2008, 02:38:21 PM PDT ) Permalink Comments [5]
Post a Comment:
Comments are closed for this entry.
Will the JDK's standard libraries be able to take advantage of language features widely available on all the other JVM languages except Java? If not, should we be seeking a different multilanguage platform that can?
Posted by Neal Gafter on August 27, 2008 at 04:54 PM PDT #
Danny, thanks for explaining the big picture, and the motivations for my particular corner of it. Here's another reference regarding IID, a short thread among us nerds at the jvm-languages group.
http://groups.google.com/group/jvm-languages/browse_thread/thread/a4b8a616eb987ca8
Neal, I don't think the new features will be locked out of the library APIs or even of the Java language, though it will require some (profitable) retrofitting and (careful) redesign. Interface injection (or something like it) will help adapt the libraries, as will closures (or something like them) in Java. The Groovy people have been playing in this space for years, with promising results.
Posted by John Rose on August 27, 2008 at 11:01 PM PDT #
Re: "The Groovy people have been playing in this space for years, with promising results."
Are there standard JDK libraries that take advantage of Groovy language features not available in Java?
Posted by Neal Gafter on August 28, 2008 at 07:16 AM PDT #
"many of the languages that are attracting the buzz that have been invented since the Java language"
Python was released before Java..Ruby at about the same time.
Posted by Dan Sickles on August 28, 2008 at 09:10 AM PDT #
I echo Neal's request for the ability to profit from invokedynamic in the Java language. I can see some good use cases for this, like making reflection-heavy code much simpler - or at least (if no new sugar is developed for this) a little faster, without the need to generate dynamic invocation stubs like HotSpot does now.
In the more formal side, Java was always the canonical language for the JVM: there is a complete mapping of JVM bytecode to the Java language. By "complete" I mean that every bytecode feature is used, and is important, for some Java feature. (OK, salvo the deprecation of the jsr bytecode.) So, it will be disgusting if there are any important bytecodes that Java cannot use - elegantly, not with horrible hacks like writing standard reflection code and having a compiler that rewrites it to dynamic invokes (which would be possible only on a best-effort basis). For some other new bytecodes no new syntax is required, e.g. a tail-call bytecode needs no new syntax, you just write methods with recursive calls in the tail position and javac uses the new bytecode. Closures are in a gray area: if the JVM/bytecode learns new tricks for this, we can just compile current inner classes into a more efficient encoding; or we can adopt one of the proposed closure specs for full profit (which I hope we do). But for invokedynamic, some new syntax is very likely mandatory for clean support. Notice that this new syntax could be very small; example:
@Dynamic x.f(y);
In this proposal we only need a new annotation, then follows the standard method invocation syntax... that doesn't need to be type-safe: the type of x doesn't need to declare a method f(Y). Yes, this is a sordid design trick, but it avoids most issues of new syntax (no new tokens, keywords etc., only new semantic rules and not even invasive ones). It's also ugly because annotations are not supposed to change the semantics of code, but that's just a rule of thumb, and it seems the other upcoming annotations will break that rule (JSR-305). And as a pragmatic solution it's infinitely better than nothing.
Posted by Osvaldo Pinali Doederlein on August 29, 2008 at 09:25 AM PDT #