—
« The End of an Era | Main | Celebrating JSR 199... »

Search

Categories

Links

Referers

Today's Page Hits: 141

Slow time in the compiler area

Oct 24 2006, 02:44:56 PM PDT »Java»Compiler Comments [9]

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 of other 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.
Post a Comment:
Comments are closed for this entry.
Comments:

If i can have a little influence to your bug list, could you append these two bugs that really annoy me.

  1. bug 6318240
  2. bug 6302954

Else, there is a simple way to simplify your generics example, by allowing to not declare the type of local variable and to infer it.
Using the syntax proposed by james gosling 

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

Posted by Rémi Forax on October 25, 2006 at 01:31 AM PDT #

I'm not sure 6318240 is a bug but I'll try to figure it out soon. A fix for 6318240 is amongst the twenty odd fixes I mentioned above.

C# uses JavaScript-like "var" to declare variables without a type but I'm not too happy about adding new keywords. I like James' idea. There are other solutions in this space and I think we need to investigate them all.

Posted by Peter von der Ahé on October 25, 2006 at 02:09 AM PDT #

Java is going to run into problems if there is a ban on new keywords. The alternatives are overloading keywords (bad idea) or punctuation (often hard to read, and often overloaded too). Part of the beauty of the language is using readable keywords like 'extends' and 'implements' instead of C++'s ':'. I hope the new 'for each' loop: for (x : y) { } wasn't the start of a trend. The reason everyone calls it 'for each' is because that's what the _natural_ syntax would be. C# has (I believe) been able to add new keywords by only allowing them where an identifier of the same name isn't in scope. This may make some code in the compiler inelegant, but seldom affects the user, is perfectly simple to understand, and doesn't hobble the language syntax to what it was in v1.0.

Posted by Jonathan on October 25, 2006 at 11:38 AM PDT #

I think the way C# uses "var" makes code harder to read and := is a very nice alternative. However, there are other tricks in C# that I find more attractive, for example, "yield return".

One of the proposed JSRs for JDK 7 is development modules aka super packages (JSR 294). Notice the examples on Gilad's blog uses "export" as a keyword but only in a particular place on (http://blogs.sun.com/gbracha/entry/developing_modules_for_development).

We have to be clever but adding a new keyword is not a valid option and we should have learned that when we added assert. But we repeated the mistake: http://jakarta.apache.org/commons/lang/apidocs/org/apache/commons/lang/enum/package-summary.html.

However, we shouldn't be to clever. James told me that public wasn't a keyword in the very early days. So you could write: 

public class public {
    public public public;
}

Posted by Peter von der Ahé on October 25, 2006 at 12:12 PM PDT #

In light of the enthusiastic adoption of dynamic languages, I think more emphasis should be given to the core capabilities of Java (compiler wise), and a little less to giving Java (the language) some of the features found in the much liked dynamic languages.

For example, I think ref 46171974, immutable types, can be an enormous improvement to the JVM with no changes to the language AND while encouraging a good practice. One of the major drawbacks of the JVM was its lack of support for numeric computations (much required in game programming, for example). An array of complex numbers is truly prohibitive both performance and memory wise.

Of course, escape analysis leading to stack allocation is a big improvement as well, but it does little for objects embedded in arrays, like in the complex numbers example.

Posted by Ron on October 25, 2006 at 03:57 PM PDT #

OK, 6318240 is a bug and I now have twenty-odd plus one bug fixes lined up ;-)

I'm not a big fan of 46171974. I think we need to see where we can get with escape analysis first.

Posted by Peter von der Ahé on October 25, 2006 at 08:13 PM PDT #

Peter, I don't see that adding new keywords is not an option. As I suspected, the C# 3.0 spec says: "For reasons of backward compatibility, when a local variable declaration specifies var as the type and a type named var is in scope, the declaration refers to that type; however, a warning is generated to call attention to the ambiguity.".

AFAIK this approach could have been taken when adding assert and enum, and could be taken in future. I'm not arguing that 'var' is a good choice of keyword, because I don't think it is, but using punctuation is not the only alternative.

Posted by Jonathan on October 26, 2006 at 01:30 AM PDT #

I have suggested an RFE for shorter syntax aimed at concise inner classes, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6389769 , and blogged on using shorter syntax, http://www.artima.com/weblogs/viewpost.jsp?thread=180638 . In both forums people keep saying that new keywords would be better. I don't see why they can't be added since we already have a source switch and with a modern IDE renaming is trivial. Also note that nothing could be as hard as assert since virtually all unit tests pre 5 used assert. In light of having many people comment that keywords are the essence of Java I have come round to the view that it is necessary to add keywords and have blogged an alternative proposal that includes them:
http://www.artima.com/weblogs/viewpost.jsp?thread=182412

Posted by Howard Lovatt on October 27, 2006 at 04:24 AM PDT #

As the originator of RFE 46171974 (immutable types) I would like to defend it. In addition to allowing stack allocation, which escape analysis may in the future allow. It provides at least the following other valuable improvements:
  1. It simplifies programming (many texts recommend using immutable types to make things simpler)
  2. It ensures thread safety
  3. It simplifies reasoning about programs (the basic premise of functional programming)
  4. It allows structures to be inlined
  5. It allows arrays to be inlined

Posted by Howard Lovatt on October 27, 2006 at 04:34 AM PDT #

Java is a trademark of Sun Microsystems, Inc.
Copyright © 2006,2007 Peter von der Ahé