Java SE 7 wish list

With JDK 6 released, we are considering features for inclusion in JDK 7. Here is a list of things I would like to see (in no particular order):

Real closures
Neal has written a lot on this topic and I support his efforts. See Closures for Java (v0.3).
Type literals
Another (minor) proposal from Neal is type literals. See Super Type Tokens and Type Literals.
Super packages
This was originally suggested by Gilad Bracha, see Developing Modules for Development and JSR 294.
Improved type inference
Using generic methods can be hard if you do not understand how inference works. In particular, why does something like this not compile:
String s1 = Collections.max(Collections.emptySet());
String s2 = Collections.max((Set<String>)Collections.emptySet());
Most developers are not familiar with implicit type arguments but you have to use them when inference fails:
String s = Collections.max(Collections.<String>emptySet());
The original GJ compiler (which was the foundation for adding generics) did better. However, the specification was found to lead to an unsound type system and we did not find an alternative specification we had confidence in. I would like to investigate if we can do better now that we have more experience.
Shorthand syntax for declaring local variables
Most people familiar with either JavaScript or C# would like to have some feature that allows the compiler to guess the type of local variables. It has been proposed to add a new keyword (var) for this purpose. I would prefer not adding a new keyword as this can break a lot of existing programs. I discussed this with Christian Plesner Hansen on his last visit to Mountain View. He had a very simple solution that I really like:
final strings = new ArrayList<String>();
Christian's solution implies that you cannot assign the variable more than once. However, the more I think about this, the more I like it. We do not need to add a new keyword and if you don't want to specify the type of a variable, you should probably not assign to it later.
James Gosling suggested using := for declaring local variables without specifying the type. One way or the other, I think the language would benefit from having a shorthand.
Shorthand syntax for declaring properties
final property String name = "Name";
property String address;
becomes
final private String name = "Name";
public String getName() { return name; }
private String address;
public String getAddress() { return address; }
public void setAddress(String address) { this.address = address; }
Notice that property need not be a keyword.
Type aliasing
A while back, Gilad and I came up with this:
import java.util.List<String> as StringList;
Notice that as need not be a keyword.
Array syntax for collections
How sweet is this:
final map = new HashMap<String, Integer>();
map["one"] = 1;
More factory methods for collection classes
We have too few factory methods in the collection classes so you can write:
ArrayList<String> strings = ArrayList.of("a", "b", "c");
Self-types
I have mentioned self-types before.
Improved compiler diagnostics
Many diagnostics of javac are confusing, especially to new users:
String s = 1;
This gives this error message:
Test.java:3: incompatible types
found   : int
required: java.lang.String
        String s = 1;
                   ^
1 error
This would be better:
Test.java:3: attempt to assign an expression of type int
to a variable with an incompatible type (java.lang.String)
        String s = 1;
        ^^^^^^^^^^^^

Things I do not Wish for

Strings in switch statements
I would not mind seeing more types accepted in switch statements but I do not care that much for this.
XML literals
I would not like to see specialized XML-literals or multi-line strings but it would be interesting to examine if we can come up with a general syntax for many kinds of literals, including XML, SQL queries, RegExps, and XPath. But then again, I do not really care too much for this.
Shorthand syntax for accessing properties
You cannot overload '.' (dot) to mean property access because it would create strange rules (what happens if you have a field foo and a method getFoo()?) and be confusing. (is it field access or a method call with potential unknown side-effects?) On the other hand, it has to be '.' (dot). Anything else would look silly. I think this is unsolvable.
Comments:

Post a Comment:
Comments are closed for this entry.
About

The Former Weblog of Peter Ahé

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today