Share

From this page you can share Java Wish List to a social bookmarking site or email a link to the page.
Social WebE-mail
Enter multiple addresses on separate lines or separate them with commas.
Java Wish List
(Your Name) has forwarded a page to you from Ajaxonomy
(Your Name) thought you would like to see this page from the Ajaxonomy web site.

Java Wish List

Tagged:  

After reading Alex Miller's predictions for what features will make it into Java 7, I couldn't help but think of my own wish list of improvements to Java (version 7 and beyond). These range from weigh-ins on the major topics of the day to minor improvements in Java's usability. Drum roll please...

1. Reification of generics. Yes, I am beating a dead horse here (it's easier when they don't talk back), but erasure sucks. Unfortunately, I think Alex is probably right when he states that reification of generics won't make it into Java 7, which means it probably won't go into any future version of Java either. Neal Gafter's explanation probably best sums it up as to why reification cannot happen while preserving compatibility. What to do? C# took the better approach to introducing generics: introduce new reified generic classes while deprecating the older non-generic ones. It is probably too late for Java to take the same approach. Quite frankly, I think that the compatibility requirement for generics in Java is far too stringent. Yes, compatibility is important, but not at the cost of the integrity of the language. Can't we admit we made a mistake and change this?

2. Improve generics verbosity. The introduction of generic type parameters, especially bounded types, makes type definitions horribly verbose. Take a look at the following example:

Map<? extends Node, ? extends Collection> map = ...;

Ouch. It would be nicer if the programmer could express bounded types in a more concise way. This might be, to borrow from C# or Scala, the use of a colon (:) to replace the extends keyword (super could use a double-colon, ::). We can now write,

Map<?:Node, ?:Collection> map = ...;

which is much better (or at least as good as it can get).

3. A more intuitive (and explicit) syntax for returns in BGGA closures. Yes, BGGA hasn't made it into the Java language (yet), but the political momentum seems to be in its favor. I dislike the use of return to mean "return from the enclosing method", as well as the use of no-semicolon expressions as kind of implicit returns. While the introduction of pure expressions may be more consistent at the compiler level (language grammar), at the syntax level it's awkward, potentially confusing, and inconsistent with Java's existing control contructs. Use of a statement form for non-local and local returns (e.g. return super and return) would be much more intuitive, though explicit non-local return syntax would be unusable outside of a closure (which complicates the life of the compiler programmer, but better him than the hordes of junior Java programmers). I'm not sure I grok Neal Gafter's explanation of why use of an expression (sans semicolon)--which is already illegal in normal Java syntax and has no meaning outside of a closure--is better than an explicit return statement. Java already has rules as to where certain keywords can be used, and the creation of closure constructs will mandate special syntax anyway.

IMHO, the simplicity of reading and writing a language trumps other concerns by a wide margin; in this view, syntactical consistency is paramount. BGGA in its current form doesn't meet this criteria. Perhaps it would just be easier if non-local returns were disallowed entirely...? I'd like to see a compelling use case for including them, at the very least.

4. Single, unified deployment mechanism for Java programs/libraries. Java has EARs, WARs, JARs, and so on. Some projects/products even include their own (e.g., SARs and MARs in Axis 2.0). It would be really nice to have a single packaging mechanism for deploying all Java programs, with appropriate variations for web applications, services, etc. Though Java modules are only intended to replace JARs, what I'd like to see is some final (and more comprehensive) form of JSR-277 (or JSR-277 integrated with OSGi) eventually replace all existing packaging formats.

5. Convention over configuration. In addition to a unified deployment mechanism, it would be nice if Java stole a few good ideas from Ruby on Rails (RoR). One of these ideas is "convention over configuration", a term coined to express the idea that one should only have to configure something if it deviates from a simple, well-defined convention. Java already has a nice example of this called the JavaBeans API. This approach could be extended to other areas of Java, especially in the way that deployment archives locate and handle various metadata files: XML Schema, WSDL, properties files, etc. There are some existing conventions regarding metadata files in Java, but they are scattered across different specifications and (in some cases) not consistently adhered to; centralization of these conventions in a specification like JSR-277 would be a good thing, as would some automatic mechanism for discovering these files without the need for system properties or other configuration.

Well, that concludes the Java Wish List, for now at least. Feel free to add your own ideas to the mix in the comments or even dispute (!) mine. Remember, not all good ideas in the Java world need to be in the form of a JSR with the attendant expert group. Let your voice be heard.