SF/JavaOne, Day 4, The Future of the Java Programming Language

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:

     feature/#reviewed/#when

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.