Mustang is not even out and there is neither a java.net or JSR for Dolphin but not of this is dampening enthusiasm for expressing what maybe or should be included or excluded. Take Tom's "Bag 'O Tricks" for example. In his blog he lists what he’d like to see in the JSE 7.0.

If I had any voice, these are recommendations I’d make. All backwards compatible and just simplifications of existing rules. I also don’t think any of these would make code quality suffer:

• No more final variables for inner class references
• No more concern for covariant method parameters for generic types
• Allow arrays of generic types
• Ability to throw undeclared exceptions
• Don’t add literal support for XML

What changes would you like to see?

I agree. It is surprising how often when adding "final" to local variables required in anomymous inner classes (blocks), how often it just works. Only rather do I resort to using the *Holder classes from the Corba package. I'm not sure it's ready for Dolphin but I think that final ought to be the default for local variables (and parameters). I see the distinction as declaring values or declaring variables. I believe that values should be the default and variables should require a 'var' keyword or something similar. Implementing this change would require a compiler pragma to turn it on to allow for backward compatibility with old code. Maybe an annotation would suffice as the pragma. To that you could add a small amount of local type inferencing.

Using C# recently I would like to see some of it's features as well as some other features in Java: - properties & indexers (this will be just syntax sugar over existing JavaBeans spec) - delegates and anonymous delegates (with some nice simple sintax so we can have closures in Java, aslo plain sintax sugar) - closures (see above) - events (also syntax sugar, can generate standard JavaBeans event code using interfaces) - using with 'Closable', very handy feature (syntax sugar again): using (Connection conn = getConnection() { ... } will generate: Connection conn = getConnection(); try { ... } finally { conn.close(); } - I agree on being able to throw undeclared Exception, but declared non Runtime exceptions still must be handled - I agree on having arrays of generic types - also allow primitives as type parameters - change the way generic works (type erasure) and incorporate type parameter data in runtime (this will brake pre JDK 1.5 compatibility, but at the time 1.7 is released wery few users will be at 1.4 or lower)

I'd like see Generics fixed so that the parameterized type can be instantiated. i.e. public class Foo { public T bar() { return new T(); } }