Saturday, 15 December 2007

Voting on Java 7 language changes

This year at Javapolis I again looked after the whiteboards.
In this post, I'll discuss the results.

Whiteboard results

The whiteboards play an important part at Javapolis
in bringing people together to discuss ideas and future trends.

This year, I chose to focus the whiteboard debate around a number of specific topics.
This was achieved by having votes on 10 language changes proposals, plus areas for new ideas for Spring, JSF, JavaEE and JavaSE.
I'm going to discuss the language change votes here, as the photos of the other boards aren't available yet.

Language change votes

Before the conference started, there were a number of language change proposals floating about, initiated by Neal and Josh at Google.
These were discussed in a late night BOF on Thursday, but this was backed up by the votes on the whiteboards.

The full results are available (with more detailed examples),
but here is the summary.

The strongest support was for Improving Generics, String Switch and Multi-catch.
Attendees were giving a clear 'yes' to these being in Java 7.

The strongest opposition was to Typedef (type aliasing) and Extension methods and chaining.
Attendees were giving a clear 'no' to these being in Java 7.

There was some support for Better null handling (with a new operator) and Properties.
The balance was slightly against, but not overwhelming.

There was positive support for Using [] to access lists and maps.
The balance was definitely in favour, yet there was a large minority against.
This was perhaps the most surprising vote.
Unfortunately, it wasn't possible to find out why there were so many 'no' votes.
My view, is that it is still worth pursuing this for Java 7.

Summary

Java being open source isn't going to be enough going forwards -
it will also be necessary to provide an open community.
Votes and direct feedback like this have a really positive effect, allowing Java's growth to be influenced by real
developers and their problems.

There should be a feature in the JDK to allow you to generate exe for your platform, that wont require jre or anything but that exe and libraries shipped by default on the OS. when that happens Everyone will be developing in java.

Popularity vote sounds like a bad way to plan for future features. It may begood to test the waters, but don't don't hesitate to add something if it isactually a good idea.

I have been using C# 3.0 and the new extension methods feature. I was not happy with the idea at first for the very same reasons enumerated here and elsewhere. However, they have proved to be quite useful to me for adding little utility methods to an external API. A simple example is adding a 'isNullOrEmpty()' method to the final String class. Despite what you may think, it is not too difficult to find and use these extension methods in C#. It is not too difficult to understand where they are coming from (your IDE tells you!)

Anyway, the clincher for me was the reason for extension methods in the firstplace. They were added in order to implement LINQ -- the .Where() and.OrderBy() etc methods are actually extension methods. Think of extensionmethods as just another way of separating your data and implementation.

If Java can add lambdas/closures, extension methods, type inference, and anonymous types then we are half way to adding a query language like LINQ.

How representative is this survey? I would have been interested in participating. All the same, it's good that there are efforts to ensure that any new features are really desired.

I'm still surprised at these property proposals, and the introduction of the "property" keyword. I don't see what that buys over public member fields. The C# syntax is all that is really needed, as it makes it easy to formally identify a property without a naming convention, and enables encapsulation, validation, and computation of virtual properties, as well as any combination of read/write access. It would allow reflection to differentiate some abitrary non-property "get" or "set" method from a real property. If necessary, an annotation could be added to existing APIs to avoid breaking method names and provide the same reflection semantics.

Simplified list/map access: yes

Extension methods: now that we have static import, it could become confusing to have extension methods too. Method hiding rules for conflicts between extension methods and declared methods (imagine an implementation of List that defines "sort" conflicting with a "sort" extension method; when you call list.sort(), what are you calling?).

String switch: a surprise ; as long as it's just syntax sugar around if...else, I suppose so, but I don't need it.

Multi-catch: how do you refer to the exception in the catch block for exception-dependent methods?

Runtime Aware Genericity (cf. your instanceof test) is realy a MUST DO for JDK7 !

When using reflection APIs, genericity is useless at this time : no way to known what is the real parametric class (for instance, unable to dynamically instanciate the real class of a list to add an item tru reflection) !

What about doing this by defining an annotation for the "genericity parameters" retention scope (runtime, compile time).

Java collection (List, HashMap, etc) should be enabled by default at runtime retention, while other type such as datawrapper might be compile time only for performance reasons.

@bjb, Since Sun has hired a compiler engineer with a PhD in solving the issues of erasure, it may be that we will see something in that area in Java 7.

@Ganesh, Native XML support is little talked about because it is little liked. I oppose it for one. There is nothing fundamentally special about XML vs any other datatype. After all, why not support JSON natively? Note that does not mean that there aren't solutions that can help - including closures.

XML "literals with expression holes" such as E4X and VB 9 are extremely useful. VB 9's XML literals are built on top of LINQ-2-XML which gives you all the LINQ query capabilities in addition to just being a much better XML api than the XML DOM. Ugh.

You're right, you can't just add XML literals and call it done. You need a 'data/query api' which is what I've been longing for in Java since trying out C# 3.0. Then one ought to probably build a LINQ-2-JSON and perhaps even allow JSON literals as well. :)