Summary
The process of proposing and specifying new language features for Java has become open and transparent in recent years. But everyone having their favorite new features list for JDK 7 carries with it the danger that truly important requirements for Java's long-term success may be missed, according to Fabrizio Giudici's recent blog post.
Advertisement
Returning from the JavaPolis conference, Fabrizio Giudici notes in recent blog post, Where are we going?, that many of the discussions about JDK 7 features at the conference and on the Web focus on issues that will only marginally help most developers in their daily work:
Sometimes too much excitement in the wrong area distracts us away from the real problems... Let's put in in another way: does somebody think that having closures or the -> operator for properties or a neat integration with a scripting language will decrease significantly the rate of failed projects? Or will significantly increase the quality of our work, and the quality of services delivered to customers?
Before answering, please keep in mind that "project success" and "quality" are related..., but are not the same thing as "reducing costs" and "shortening the time-of-deliver..."
My answer is a resounding "no." Having better tools is important, but the key to success is another thing: the process.
At the core of Guidici's concern is that developers looking at features of other languages wish Java had some of those language features as well, such as closures, for instance. Because Java is now developed in an open and transparent fashion, a veritable smorgasbord of proposed language features has emerged, some with a good chance of being implemented in JDK 7. Guidici laments that:
I'm scared at the thought that we all end up in the rush-fashioned, Microsoft-style method "give the customer what he wants today—or he believes he wants—, take the money and don't think of the future." I'd be really sad if this trend will drive the Java evolution—it would be a betrayal of the initial promises.
What of the proposed JDK 7 features do you feel would make you truly more productive, and what proposed features do you think would be better left out of JDK 7?
> many of the discussions about JDK 7 features at the > conference and on the Web focus on issues that will only > marginally help most developers in their daily work:</p> >
For many years, Java abided by the KISS principle so strongly that we saw no language level improvements at all... Enter .NET/C# with some really nifty features like annotations, assembly versioning, cross language interoperability etc. etc. and all of a sudden, Java's "no change" policy seems somewhat unwise - these new features do boost productivity significantly.
However, adding new features with reckless abandon will only harm the language's originally stated goal of simplicity, morphing it into a many tentacled monstrosity. Personally, I see C# heading in that direction, with so many new language bells and whistles being introduced (which are of marginal utility) that people will soon start using only a small subset of the features. To me, features that are hell bent on reducing verbosity are of marginal utility, e.g. iterators and operating overloading in C#. I personally prefer code that reads simply, without having to mentally overload the meanings of different symbols. Saving a few lines of typing isn't worth cryptic looking code that fries your brain to figure out.
I also recall seeing a demo of "LINQ" (Language INtegrated Query), which may be introduced to C#, which appears to have high learning curve/complexity costs in relation to productivity boosts. Perhaps these fears are merely resistance to change. Initially, I remember being horrified by the idea of partial classes, but started to appreciate its usefulness after seeing how visual studio benefited from it. LINQ may also prove to be just such a case.
The key appears to be to tread the middle path and how to evaluate the "utility" will be the problem. Too many features and the language itself becoming so large that it leaves people scratching their heads trying to figure out what's going on. Too few, and you are again left scratching your head trying to figure out why it's so hard to do simple stuff. One thing is for certain: better to leave a feature out and add it later than add it early and repent forever...
> The key appears to be to tread the middle path and how to > evaluate the "utility" will be the problem. Too many > features and the language itself becoming so large that it > leaves people scratching their heads trying to figure out > what's going on. Too few, and you are again left > scratching your head trying to figure out why it's so hard > to do simple stuff. One thing is for certain: better to > leave a feature out and add it later than add it early and > repent forever...
... or, design a language with a relatively simple core that is expressive enough to build powerful libraries. This way a library can serve as an extension to the language (see C++ STL or Boost libraries as an example).
> ... or, design a language with a relatively simple core > that is expressive enough to build powerful libraries. > This way a library can serve as an extension to the > language (see C++ STL or Boost libraries as an example).
That would seem ideal...
There might be exceptions however. For example, the synchronization support built into Java/C# at the language level can be quite a convenience, although it could have been implemented at a library level.
As others have noted, the problem with Java is that it's not extendible, so you have to wait years for something like the Java 5 iterate-over-collection for syntax.
So some people complain about feature-itis, but there's really little choice. Either Java (the language) is extended or there's an official, concerted effort to design a new language that is interopable with Java.
Let's let Guy Steele design it this time, instead of Gosling;)
> As others have noted, the problem with Java is that it's > not extendible, so you have to wait years for something > like the Java 5 iterate-over-collection for syntax. > > So some people complain about feature-itis, but there's > really little choice. Either Java (the language) is > extended or there's an official, concerted effort to > design a new language that is interopable with Java. > > Let's let Guy Steele design it this time, instead of > Gosling;)
Oh god...Common Lisp is an incoherent mess. An amazingly powerful mess, but a mess none-the-less. Of course that's what you get when you take the union of several dialects of essentially the same language...
> > Oh god...Common Lisp is an incoherent mess. An amazingly > powerful mess, but a mess none-the-less. Of course that's > what you get when you take the union of several dialects > of essentially the same language...
> that many of the discussions about JDK 7 features at the > conference and on the Web focus on issues that will only > marginally help most developers in their daily work:</p>
if at all, I think most people would be hindered by the increased workload provided by less readable, more errorprone code and the ease with which the unwary can use the new proposed "features" (bugtures would be a better term) to produce buggy and unpredictable code.
> <p>What of the proposed JDK 7 features do you feel would > make you truly more productive, and what proposed features > do you think would be better left out of JDK 7? </p>
IMO nothing that was introduced since 1.5 has any relevance at all except for the highly questionable "me 2" reason, introduced for no other reason than to be able to say that "Java has it too" when confronted by people using other languages because it has some feature. No thought seems to go into anything except that, being able to trump every other language when it comes to feature richness.
Previous Topic
