I listened to the Drunk and Retired’s Java 7 wishlist podcast this morning and had a few comments. If you haven’t listened to the podcast, then some of this may make no sense… :)

• Properties – I think something around properties would be cool, but I haven’t seen a properties proposal that I’m excited about yet. I think in this case, the devil is in the details. I concur with Charles that defining it on interfaces would be nice. So here’s my reason not to have properties (I’ll take my chances that Charles won’t kill me): no implementation/proposal exists that doesn’t suck in some way. And perhaps more importantly, maybe a non-sucky properties proposal is not possible. I don’t know. If the actual implementation added properties but made the whole language more complicated as a result, then I don’t think it would be worth it.
• Closures – I think from what I’ve read, it is far from certain that closures (or any other language features) will make it in to Java 7. Buried in this recap from Elliotte Rusty Harold on JavaOne, you’ll see near the end that Neal Gafter himself (the most visible proponent of closures) said at JavaOne that he didn’t think any language changes would make it into Java 7. So, at this point, I’d say no one really knows whether closures will be included. Generally, I think having closures and some form of control abstraction would be nice, but as with properties the devil is in the details.
• Superpackages – JSR 294 defines the superpackage stuff, which is really just a way of specifying a new visibility scope above the package level. So if you have a component with some public interfaces in a package and some private implementation details, you can declare that users of your superpackage (which at runtime may be a Java module ala JSR 277) can see only the interfaces, and not the implementation. This is something that can actually be checked at compile-time as the superpackages are defined with the code. You can already see tools doing this stuff – for example in Eclipse (really in OSGi) you can declare which parts of your project/bundle are public. I gather that there are some important differences between OSGi and JSR 294 in the granularity of definition.
• Named parameters – I have seen no one propose this, but I’ve been thinking for a while that it would be really helpful in situations where you have lots of optional parameters. It would be great for constructor injection, argument passing on a program interface, embedded DSLs/fluent interfaces, etc.
• Removing interfaces – I think it’s crazy to talk about removing interfaces. That said, I kind of understand what Charles is asking for and the closest thing I’ve heard is Stefan Schulz’s interesting proposal for meta-interfaces which I really like. It’s a way to define an interface of static methods that a class must “conform” to. I think generally the use cases discussed in the podcast are more instances of bad design, IMHO.

If you’re interested in more Java 7 stuff, check out my Java 7 page.