Just got out of a fascinating talk with Mark Rheinhold and Gilad Bracha about future enhancements they see in the Java Programming Language.  The talk started out with a very interesting discussion about the philiosophy of language design and how the Java Language Designers take a very "pragmatic" approach to the entire process.  They espouse readability as a core tenet, and list it as one of the primary reasons for excluding features like operator overloading and macros.  After all, (except for the very very special java.lang.String class), when you see operators in java you know you're dealing with a built in primitive type.  This kind of knowledge is very powerful since it means that whenever you see the expression "a - b" you know clearly what that means and it's easy for you to read and understand the code.  Whereas in a language that has operator overloading, suddenly every single expression becomes suspect.  Having used code before that did things like overload the assignment and parens operators in incredibly crazy ways (by eventually connecting to a DB to pull down up to date values from) i can understand the desire to make the portions of their language that can execute arbitrary code quite explicit.  They also discussed features that would most likely not be in java for a very long time (if ever).  I don't recall the complete list, but it did include things AOP and multiple return types (bummer).

After the into Mark started talking about integrating XML data creating and access right into the Java language proper.  They're in very early investigationgs on this topic, so it's most likely that any path they take will not look anything like what i'm going to talk about here. He mentioned that trying to introduce literals like <foo> directly into Java language proper because of the ambiguity with generics.  So they're actually looking at bringing in a new way of introducing xml with the # token.  What would that look like?  Well, say you had some xml element and you wanted to add a new child now to it?

void AddReview(Element feature, String user, String date)
      feature.add(#reviewed { #who { user }, #when { date } });

This would then get tranlated behind the scenes to the 20+ lines of DOM code it would take to normally do this.

To access elements you could do stuff like:


i.e. / would be overloaded on the xml type to access children.  Of course, all this gets translated into appropriate dom calls that will do things like getting children by names and whatnot.  Of course, in this system you don't necessarily have strong or static typing, but it's something they're thinking about as well.

Finally, Gilad came up and talked a lot about how integrating other language onto the JVM was quite difficult and is one of their current dissapointments.  There are many language features from other languages that just dont' translate well to the JVM as the JVM was really created to support Java first, and everything else a distant third.  So if you're a language with multiple inheritance, multiple dispatch, that is dynamically typed, then you're kinda SOL.  Of course, you can hack it on (usually with your own VM), but you end up with a Franken system whose leakly abstractions are going to show up somewhere and will be quite ugly.

So they're (hesitantly) thinking about adding a new bytecode to the JVM , called "invokedynamic" whic would go into the same family as "invokevirtual/static/interface/special".  However, unlike the existing bytecodes, it would not require all the types to be known at compile time.  There are still many open issues with this, but they feel that this will be a good first step with helping scripting languages run much better on the JVM

All in all, very interesting stuff.  I was hoping to see more dramatic and interesting stuff coming through the language, but i do understand where they are coming from.