Wednesday Jun 01, 2011

I do not want Short Property Syntax Anyway

Hans Muller just convinced me that I didn't want a short hand syntax for declaring properties after all. Hope it isn't too late.

Kitchen Sink Language Answers

I got a few questions from a reporter on the Kitchen Sink Language. He wanted to know what prompted me to start the project and what my goal is. Here is my reply:

The Java™ programming language is defined by the JCP. This is a good thing as it ensures that the entire community is heard. We should also be conservative when selecting which features are added to the language. Otherwise, the language may become a mess. This was explained in Evolving the Java Language by Bracha, Hamilton, and Reinhold.

We want the main branch of javac to be stable and primarily focus on implementing approved features. On the other hand, we must experiment and have fun to get a feel for new language features. Most people seems prefer evaluating new language proposals by using them on their own code, rather than reading abstract specifications and proposals.

As you may know, I'm the Java compiler (javac) tech lead. I see a lot of proposal for enhancing the language and our team has to turn down most. So how can we experiment? James solution is the Kitchen Sink Language which will be a forum for trying out crazy (and not so crazy) ideas for language enhancements.

Over the winter holidays, Rémi Forax implemented two different proposals for language enhancements. This is exactly the kind of community James and I would like to encourage so we were happy to see Rémi's work. On the compiler-dev mailing list, Rémi's work prompted Ted Neward to suggest that we do something to coordinate future experimental features. So I felt this was the right time to implement James' idea.

Now it is time for me to create a vendor branch so we can start experimenting.

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.

JDK7 b05 compiler fixes

In JDK 7 b05 (open-source bundles), these compiler fixes will be included:

6192945: Declaration order of interdependent generic types should not matter
6278587: Compiler fails to infer correct type for under-constrained type variables
6356673: javac incorrectly generates "reference to <xx> is ambiguous"
6495506: Cast inserted by generics can cause IllegalAccessError

I cannot predict when this build will be available for download because of the upcoming holidays. If you wonder why the list is smaller this time, consider this: we just launched JDK 6. Naturally, we have been focusing on that release as well as looking towards the future. Besides, we still have a ton of stuff to figure out in relation to open source.

Speaking of open sourcing: I made the ultimate sacrifice and installed Windows. :-(
Do not try this at home!

Fortunately, my trusty laptop still has a real operating system.

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

Peter,

Don't forget we also moved offices during this time; an activity never to be undertaken lightly here at the big S.

-- Jon

Slow time in the compiler area

You may have noticed that I stopped posting my bi-weekly summary of compiler fixes. I plan to pick it up again when JDK 7 development takes off.

Right now is kind of a slow period and that is nice. Later today, JSR 199 should move to the final approval ballot (FAB). This is the last stage it needs to go through before the final release which is delivered in JDK 6. All JSRs including the umbrella JSR for the release must go through this process before we can ship the release.

The only changes that we will make to JDK 6 at this time is to fix show stopper issues. This means that most of my team is looking at either improving documentation, writing sample code, making it easier to build the compiler, or JDK 7.

Personally, I'm procrastinating on writing compiler documentation by fixing bugs to go into JDK 6 update 1 and JDK 7. So far I have lined up a little over twenty fixes. I'll give a summary when I know more about how you can get them. It is most likely JDK 7 b02 but we do not have weekly builds since we are focusing our release engineering and quality resources on JDK 6. So I don't know when.

Besides pruning my bug list, I'm also helping with figuring out which language features Sun would like to see in JDK 7. Clearly, we're looking at code abstraction but there is a lot ofother ideas floating around. Another thing we are investigating is if it is possible make generic types a little more convenient. For example, code like this is pretty annoying:

Map<Comparable<? extends Number>, List<Number>> x =
    new HashMap<Comparable<? extends Number>, List<Number>>();

James Gosling has returned to the Java programming language and I really like his approach. I think the only problem we have is that we have too many good ideas and just one tiny release to put them into.

I also decided to update the about page on this blog after reading Jakob Nielsen's top ten on blog usability.
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