OK, even I have read through the poposed new features for JDK 1.5, and I have mixed feelings. I very much like the proposed new for loop. It will make all our lives simpler. Some people think the syntax is confusing, but I think that is total bull if you consider all the cruft it will replace. A decent IDE like IntelliJ makes it a snap to create the Iterator/hasNext()/next() and cast, but it is just so verbose. The new syntax is just superior. It must however be noted that it will not work for Enumerations, just for collections with an iterator() function, or arrays. An OK tradeoff, I think. Enums sucks anyway, and including also Enumerations would just make things complicated.
Static imports. No, I would just say no. It makes something complicated out of something that is elegant and simple. Sure, I can see that it sucks to have to write Math.sqrt(x) all over the code when just sqrt(x) is fine in all other languages, but there is a simple workaround: just declare a sqrt() function in your class that uses the Math.sqrt() function to do its work. Did I hear slow? No, HotSpot should inline your local function. Besides, this is something that only makes sense for matematicians, since only they have functions with universally recognized function names. For everyone else, the name of the class where the function belongs is an extra verbosity that is good. This proposal is also overly complex - go have a look, and prepare to get overwhelmed. The proposed "static" import qualifier is also badly chosen, since with this new proposal you don't only import static members, but also the new proposed enums. Would it be such a disaster to introduce a new keyword, say "inner" (that better describes what is going on)? Sure, it would break some code, but how much work can it be to do a global replace of "inner" to something else in a project? How much code did we have to rewrite when assert was introduced? Not much, right?
I think the core of the matter is that the people who wrote the proposal for static import only had the programmers point of view. Sure, it would be cool to be able to write just sqrt(x) instead of Math.sqrt(x), but for the reader of the code, MailUtil.send(x, y, z) is much easier to understand than just send(x, y, x). The reader would have to go through various static imports plus all base classes to figure out where the hell that function is declared. Unless you have an IDE like IntelliJ, of course, where Ctrl+Alt+b sends you straight to the implementation of a selected function.
Enum. Oh. My. God. How could something so simple get so screwed up. They are proposed to be like a class that can implement any interface, and contain any kind of function. WTF? Sure, you'd be able to write all kinds of cool things that would make programming easier in 0.1% of your code. For the other 99.9% it is just total overkill. The enums used in the examples that comes with the proposal are all screaming to be mercy killed and reborn as classes. If I had any saying here, I would just send this proposal back to its author with a suggestion to greatly simplify and cut down on features. This is NOT what people have been asking for, but instead a wet dream nobody else wants to participate in.
Autoboxing. It seems like a simple enough proposal, actually. It gets a thumbs up from me.
Generics. As I've said before, I've so far never seen a bug caused by an orange in the apple basket. And the code actually gets to be more complex than before. There is a certain kind of beauty with a container of Object's. The only crux is the downcast, and I don't see that as much of a deal. Also, the new for loop will remove it for us. Generics does give us a bit safer programming, but not much. I also have a vague recollection from reading the proposal a few years back that the proposed code for using generics was sometimes rather surprising and non-intuitive. Sorry, don't remember the details. Just spreading some FUD.
Previous Topic
