To my knowledge, what you're talking about is still on the table if it can be worked out in a reasonably sane manner, but it's tricky. Not that this is an excu

To my knowledge, what you're talking about is still on the table if it can be worked out in a reasonably sane manner, but it's tricky. Not that this is an excuse not to do it, but it's not straightforward even to spec out, let alone agree on and implement: Java has some painful differences between variable and function namespaces, not the least of which is that methods are polymorphically resolved whereas member variables are looked up based on declared type. So what should happen we try to assign a function as a variable: should it be looked up based on runtime class, or declared class? Either way, there are going to be gotchas, and what you'd think might happen is not what actually happens. There's just no way to allow Java methods to become transparently interchangeable with variables in the face of inheritance, so some of Joe Java's assumptions will probably have to be broken for it to work right. IMO it would be best to just go back and rewrite the variable namespace rules to be a little saner (is it ever really necessary to shadow a superclass variable? Scala gets along fine without allowing var overriding...), but that's never going to happen, so... This leads to other frictions, too: one issue that's been causing some friction is that nobody has yet fully worked out how to allow closures to be called using m(args) syntax instead of m.invoke(args), because of these same namespace issues. That one is on a lot of todo lists because using the things will be overly verbose if it's not done, but there's a lot of subtlety in the edge cases, so I'm not sure how it will all fall into place. Everyone should keep in mind, though, the proposal linked on this page is a very rough draft, and is likely to be altered in many, many ways. Neal Gafter has been working pretty hard to try to bring his latest proposals (see http://www.javac.info/ http://www.javac.info/ for links) closer to where the official proposal is likely to go (i.e. a simpler and slightly less powerful compromise), so more of what was in BGGA might show up in the final Java 7 spec than Mark's strawman proposal would indicate.