Link Details

I've been trying to formulate a coherent response to this, but my only reaction is "no no no, please do not do this, no no no...... no." The compiler catching these things is nice, but it's not worth the price of a completely unreadable language.

It's frustrating to see people want to shove everything in at the language level when they should just be left at the API level. If I need null-safe Collection operations, provide it in a separate library. Done. Written, never have to worry about a null pointer exception when making an iterator again and my code can actually be read by a human being. Most of us do some sort of sanitation of our inputs anyway so why do we need this?

Oh benevolent masters of the Java language, STOP! Stop adding things to the language. You're not losing long-time supporters of Java because ruby/python/lisp/javascript/etc has some language feature that Java doesn't. It's because you keep proposing and implementing crap like this. You're making the language MORE difficult to use and that's why so many shops haven't even moved over to Java 5 yet (let alone 6 and probably won't even when 7 comes out). We came to Java because it was a simple language that didn't require you to sift through archaic symbols of syntactic sugar to use. You're losing that, and as a result you're losing developers to other languages. So stop bastardizing the thing that Java had going for it -- a simple langauge with so many powerful libraries it would make your head spin.

Sorry for the angry rant, but I've listened to pitches for Java language features in the past (almost none of which I really enjoyed) but never did I thought I would hear another one that ranks up there in sheer pointlessness as the whole "xml in the language" bit.

> Oh benevolent masters of the Java language, STOP! Stop adding things to the language.

Are you kidding? Java has no master, that's part of the problem. If only it had, then we'd have a modern language that work with us rather than against us. No, IDE's and various annotation indirection levels and buried DSL's is not the same! Type inference please. Properties & events please. Traits or extension methods please.

If you wish to remain in Java 1.4, by all means, don't let me stop you. But please don't hold traffic back because you fancy driving your veteran car with manual clutch and puristic curves.

I'm not suggesting for a second that we slow anybody down. I just question why propose a language-level solution to a problem that can and should be solved at the API level to benefit a very very small portion of the user base. Java can continue to get better, but focus more on an APIs which truly lets the programmer choose what features their project uses and doesn't use. Don't force these abominations of language features on every developer who touches Java afterwards. Seriously, have we learned nothing from C++?

Take Ruby for instance. A few years ago almost nobody cared about Ruby. Now it's hard to go to any technology site where people aren't singing some of Ruby's praises. Is it because the language became awesome overnight? No. It's because of Rails -- an API level solution to the problem of writing web-based applications in Ruby. But the Java philosophy over the past few years has been that if there's a need in the Java community (regardless of magnitude), add language support for it. It's the wrong way to go. There are a number of things that can be done to make Java better, and it has little to do with adding language features.

I'd argue, that many problems in Java stems from the fact that the language has remained untouched (unfixed) which have left API's as the only solution. I don't think you can compare a managed, statically and strongly typed language like Java with C++. The problems of C++ stems from the fact that you can get away with anything. Case of point; have a const that you'd like to modify? Just cast it away.

Also, I don't think your Ruby argument works. David Heinemeyer Hanson chose Ruby, specifically because it is so darn expressive and gave him freedom to design a framework that would work WITH the user and not against him. Of course, Ruby is dynamic and goes too far in expressiveness, but it sure would be nice to have a little of that language leniency in Java. Perhaps then we did not need as many convoluted applications of patterns as we presently do.

If you look at the recent developments in Java, much revolved around embedding a DSL. But because Java lacks the expressive means, this has to be done as String tokens (typically inside annotations, case of point; JPA query language, beans-binding, expression language) and to javac, this content is just some string, so forget about type safety, code completion etc.

"Don't force these abominations of language features on every developer who touches Java afterwards."

You can still write Java code targeted to the 1.0.2 JRE, back to the nightmarish pre-1.1 event model & AWT and it works on the current JRE release.

I agree to some level that they should be more wary of adding new language features -- though it's also generally true that you don't have to use them (just upgrade your apps to take advantage of the evolving runtime optimizations, etc. but don't use the new features). I personally took the time to learn generics/auto-boxing/etc. because it fixed some problems that had been annoying me for a long time... but haven't put much effort into annotations at all yet. If they extend them, chances are I won't even notice.

Whatever happened to the term "Engineer"?
,