Small Java 7 Language Changes

Project Coin is the name of the OpenJDK work covering small language changes for Java SE 7. The current Java.net poll question asks which of the proposed Project Coin features is most interesting. I often like to gauge the interests of the Java developer community based on these poll questions and their results. In this case, I am not going to analyze the results because, at the time of this writing, the vote total is just over 100. Instead, I am going to describe what each of the proposed features are and what my own level of interest in each is.

The choices to vote for to answer the question of which Project Coin feature is most interesting are: switch statement support for Strings, ability to catch multiple exceptions with the same catch clause, using type parameters for more concise constructors, call methods with exotic names, bracket notation for collections, and any feature not already listed. I will now briefly summarize each of these features and state my own level of interest in each feature.


Strings in Switch Statements

There was a time when I really wanted this feature. In fact, I have even written about this feature in the ActionScript language and compared it to Java. This feature is less important to me now that we have the powerful and typesafe enum. That being said, I know several Java developers who prefer Strings because of greater flexibility. For them, switching on String would help them avoid long if-then-else blocks.

For me, I generally find that I only really use switch for things that are finite and for which individual differences are more frequent than similarities. In other words, in many cases, if something needs such flexibility that it is better supported by Strings than by Enums, then it is typically the case that I don't need to switch on individual values anyway.

Many people have expressed interest in having the ability in Java to switch on Strings. Accounts of this interest are available in Java Switch Statements Should Allow Strings, Not Just Ints, A Switch on String Idiom for Java, Java String Switch, and Switch on String in Java.

In the end, I have a slight preference toward the ability to switch on Strings, but the emphasis is on slight.


Multi-Exception Catch

This is another "small change" that many Java developers have requested. For example, the blog posting Wanted: Multiple Exception-type Catch Blocks talks about why this would be useful. This feature is described in Alex Miller's section on the Improved Catch Clause.

I have run into the situation more than once when it would be nice to catch multiple exceptions and handle them with the same exception handling code. I have found this to be especially true when using older libraries and frameworks that make use of large sets of checked exceptions. For example, in working with Remote JMX, there are many common checked exceptions one encounters. The developer is usually forced to either catch a very general exception to handle all of them or to list each one out individually to handle them differently. Being able to combine two or three closely-related JMX exceptions in the same handling block would be handy.

Even with the benefits described above, this is still a feature for which I only have a slight preference. With the trend toward unchecked exceptions except for things that can really be expected to be handled, I have run into this problem far less. Also, there seems to be a trend for frameworks to use exception hierarchies and I can often catch the parent exception for general exception handling for that API or framework.


Bracket Notation for Collections

This feature refers to the ability to reference a particular item in a Collection with square brackets similar to how Arrays are accessed. Shams Mahmood makes a persuasive argument for a similar feature (instantiation of a collection like an array) in his blog posting My Java 7 Wishlist Regarding Collections. In the blog posting Double Brace Intialization, Isa Goksu describes how double curly braces apply an anonymous inner class and obtain a similar effect. He also points out multiple issues with this approach. The Java Idioms site covers this double brace initialization approach in even greater detail.

The argument for the ability to treat Collections more like arrays is that this syntax is easier and more concise. According to this argument, Collections would be even more widely accepted and used instead of arrays if Collections had this array-like syntax. This is another feature that could be handy, but I only have slight preference for.


Concise Constructors with Type Inference

This feature would allow the compiler to understand the generic types being used in a constructor based on the newly instantiated object's data type rather than necessarily needing to redeclare the generic type as we do today. The pain associated with this redundant type information is lessened by today's powerful IDEs. That being said, it also seems sensible that a statically typed language like Java could take advantage of the fact that it knows the generic type on the left side of the equals sign to imply what static types are used on the right hand side of the equals sign.

It's become a tiresome theme, but this is another feature that I won't mind having, but also won't lose any sleep over not having. Again, I have only a slight preference for the addition of this feature.


Exotic Method Name Calling

The aim of this feature request is for Java to allow methods to be called in non-Java languages. Many of these non-Java languages allow their methods to have characters not supported in Java method names. While this would be of the least benefit to me in the short-term, I could see this feature providing the greatest long-term benefit as it is likely that we'll see the trend toward mixed language use continue to grow.


Conclusion

It is not surprising that "small language changes" tend to be, for me at least, also smaller in terms of enthusiasm and excitement. Of course, I also don't have strong feelings from a negative perspective on these small changes. If all of them were implemented, I would occasionally benefit. If none of them were implemented, I'd only occasionally miss them.

One other observation that can be made from looking at these Project Coin changes is that many of them meant more to me in the past, but the passage of time and improving language features have reduced my degree of interest in these features. The long-awaited arrival of the Java enum, the rise of the powerful Java IDEs, and other advancements have reduced the urgent need for these changes to some degree. The one exception to this is the exotic method name support, a feature for which need is actually relatively new and is likely to grow rather than diminish.

The final personal observation from this is that, at least for the small things, the Java language is very mature and there are very few small things that I have a strong longing for. In other words, I'm pretty happy with the Java programming language generally.