Projects for javac

As you know, the syntax and semantics of a legal Java program are described in the JLS, so javac cannot just accept any program it likes. Patches to javac that change the space of accepted programs will always be contentious, but patches that improve the usability of javac itself would be well received by many people. There is obvious "low-hanging fruit" in diagnostics, because javac's reporting of type errors is less than ideal. Here are some ideas for mini-projects which would have a huge impact on programmer understanding and productivity:

Type derivation
An 'inconvertible types' error gives the source and target types. What is the series of type rules that derived them? (This would help to explain why compound assignments sometimes behave surprisingly with boxed operands, even though the behavior is there for a reason.)

Type membership
I recall numerous bug reports where javac appeared to get accessibility wrong, whereas in fact the submitter was confused about the members present in some types. These reports inevitably featured multiple packages, public types, package-private and protected members, and pathological inheritance. Only careful reasoning about inheritance, and hence the exact membership of a type, would explain javac's (correct) behavior. javac knows this membership already - why not display it? (The same can be said for intersection types.)

Formatting
This is a simple one: display messages in a hierarchical way, and have heuristics to simplify or abbreviate qualified class names. You could also imagine having short-form and long-form versions of some error messages, where the long-form version suggests a way out of the problem.

Capture conversion and type inference
Those 'capture-of-451#...' messages are tough. Why not display the type of an expression before and after capture, including the upper and lower bounds of synthetic type variables? Constraints for the formal type parameters of a method would be good to know as well. In fact, any additional info about the operation of overload resolution is valuable when no most specific method is available.

I wouldn't be surprised if the utility of an error message is inversely proportional to the amount of code within javac which must be unravelled to create it. In any case, these ideas will hopefully stimulate some discussion and experiments in the OpenJDK compiler group.

Comments:

Those are all excellent suggestions for improving javac.

But another low hanging fruit is that javac is apparently still single threaded. With multicore cpus already the present reality, and only getting more so in the future, you really do need to change this.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4229449

http://forum.java.sun.com/thread.jspa?threadID=5255292

Posted by sam smith on February 01, 2008 at 02:24 PM PST #

It seems another piece of low-hanging fruit might be in the form of replacing equals() with ==. Any takers?

Posted by Samuel Richter on February 02, 2008 at 04:38 PM PST #

@Samuel
With respect, that is not a piece of low-hanging fruit. JLS 15.21.3 defines the semantics of == as object equality ("shallow" comparison), not value equality ("deep" comparison). A Java compiler cannot interpret == as invoking the equals() method.

Posted by Alex on February 08, 2008 at 11:06 AM PST #

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

Alex Buckley is the Specification Lead for the Java language and JVM at Oracle.

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
Feeds