Ola Bini has posted an interesting list of features he'd like to have in a hypothetical Java 3.

There are some points I definitely wouldn't like, such as "No primitive arrays." - I know they are a pain to have in the type system, but getting rid of them and thus making it nearly impossible to implement custom data structures is really not the way forward. One should try to come up with a primitive collection-like data structure that better fits into the language and type system, but dropping them altogether is not a good idea.

What I'd really like to see in Java 3 are two things: more syntactic sugar for common things, some important platform features, identifiers as first class citizens, a structured way out of the type system, and named parameters. Which is roughly the order of difficulty in implementation and unlikeliness of having these features actually appear :-)

• Syntactic sugar would be stuff like allowing the [] and []= operators on everything that implements List or Map, respectively. Plus collection literals (Maps and Lists, or Arrays) with type inference for the generic collection type. This really doesn't harm at all, as it totally fits with the language as-is. I know it's "just syntactic sugar", but this could really make a lot of stuff easier.
• Platform features - we need a way to reliable and possibly forcibly reload code, possibly modifying the runtime layout of objects, adding methods and fields. Plus, we need a way to reliably kill rampant threads. And we need a way to reliably isolate certain application/platform layers, such that they can be independently reloaded, garbage collected, etc. The latter one might be the first step in a solution for the first ones. I know this is hard, but if Java-as-a-platform is supposed to be cool (and to grow), we really need this. There must be a way to achieve this - somewhere along the lines of passing immutable message objects between layers.
• Identifiers as first class citizens. Everybody wants methods/functions as first class citizens, and I agree, but something else we will need for that, and what would be really useful in other areas, would be identifiers as first class citizens. Proposed syntax would be something like this: Identifier id = &java.lang.String.toString;
id = &com.corp.MyClass.myField;. These should come in three flavors: locally scoped, fully resolved, and attached to a certain instance (Method handles alike). This would simplify a lot of the meta programming, in particular all the APIs like JPA that need to identify certain fields of a class. This is somewhat similar to the Methods-as-first-class citizens, but a more general feature that could coexist nicely with these.
• Escaping the type system is done all the time by Java frameworks, even today. Everyone is using some sort of reflection or XML configuration (shudder) to invoke methods on unknown types, inject fields, or whatever. But it's an unnecessary pain to do that, so I'd propose to introduce a "var" type that allows calling anything on it:

  var foo = somebla();
  foo.myMethod(); foo.somethingElse(); ...
  

  If a method doesn't exist, a well-known method could be called (think "method missing"). And if all breaks, this would simply give a NoSuchMethodException or similar. This would allow leaving the type system without paying such a large tax for it. Also, we should allow a much simpler way of reflection, e.g.:

  String methodName = "run";
  Object x = ...;
  x.(methodName)(args);
  

• Named parameters are actually the best thing since bread came sliced. Our way of calling methods just by putting arguments in parenthesis in some order is wrong, wrong wrong. This comes from the bad C inheritance where you'd simply push stuff onto the stack, with no checking whatsoever. We don't need this today, and having named parameters makes a whole class of nasty errors highly unlikely. E.g. think about calling MyConstructor(String,String,String,int,int,double,String). How often do you mix up the order? This would also allow for much better error messages from the compiler. Of course, this feature comes from good old Smalltalk (at least for me): Point moveToX: 12 withY: 15 andTitle: "Hello".. Much better.

Maybe one should start a project to actually try this stuff out. I know that many people have stated that Ola's list is just a description for a subset of Scala (or some other language), and they are right, in some sense. But this is an important point: I don't want all the complexity of Scala. And I don't like their implicits, the "object" feature - which is syntactic sugar for something that shouldn't be there at all, static must die -, the sometimes cryptic syntax, the weird rules about operator/method precedence, and so forth. This deserves further qualification (a lot), but I'm just not happy with Scala.

I guess one should also look at the work done by Gilad Bracha (Newspeak) and possibly Ian Piumarta/Alan Key in their COLA stuff. The former, because Bracha introduces some really nice and useful features, the latter just because it's totally awesome :-)