Well, the JDK7 Project is underway, and despite the fact that I am being moved into the .NET world for some new projects, I wanted to leave some parting thoughts with the Java community. By no means do I consider myself the ultimate authority on the following topics, however, these are a few things that I propose would make Java a better, more friendly, more flexible language.
So here they are, in no particular order, my wish list for Java 7:
1. No More Primitives!
Seriously, primitives had their place and their time, but it's time to let them go. If you're using a boolean instead of Bool to save system resources, then you need to get a server that was made in the last decade. Performance is no longer a valid argument on this one (and that was about the only argument there ever was). OOP is OOP and primitives don't belong in OOP!
Let me put it this way... how many times have you wanted to do something like this:
return (object1, object2);
See, now you want tuples too. Of course you always have the option of shoving them into some sort of a generic Collection, and then recasting them on the other side. But here's the problem: Collection's are meant to hold a collection of objects, they are NOT intended to be a form of community transit.
Another cool thing about tuples is they let you swap values without using a temporary variable, e.g. (x,y) = (y,x). That one's just for free...
3. Singleton Class Modifier
Do we need it? No. Would it be nice? Absolutely. Just let rules of a singleton Class be handled by the JVM, rather than leaving "singletoness" to be implemented by the designer. I suppose more importantly, singletons would be made thread safe by the JVM, a consideration that is often overlooked by singleton design patterns.
4. Scriptlets Inside JSP 2.0 Custom Tag Bodies
Ya, I know this is JSP, not strictly Java - but I'm stroking with a very broad brush here. I mean, why in the name of all that is good can't we do this?? Yes, scriptlets are inherently evil since the advent of JSTL, but what about those of us cursed with terabytes of legacy code that we do NOT want to convert to JSTL functions? Presumably custom tags still implement doBody() at some point or another, which already supports scriptlets. So again, why???
5. Heredoc String Support
This again is something that we don't need, but that I would definitely like to see. Java developers generally externalize any Strings large enough to justify heredoc format into a properties file - but this has its limitations; take for example a String that needs to contain a variable. I really don't care how it's implemented (e.g., StringBuilder, StringBuffer, plain Jane concatenation), but I want it.
While Java let's you get close to closures (using anonymous inner functions), your code ends up being really ugly and hardly readable. I think closures would be a big step towards making Java a more flexible language (without hurting your eyes at the same time).
7. Rationalize the Collections API
This would be big, it would be rough, and it would make a lot of developers angry. The idea of it actually scares me a little, but I'd contend that it has to happen sooner or later - and the sooner the better. Since my whole argument here is completely stolen, I'll just let you read it at the source.
And that's it. I wanted to make it a top 10 list, but I really didn't have enough to go on. I realize several of these topics are controversial - so let's hear it in the comments.