Projects for javac
By abuckley on Jan 23, 2008
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.)
- 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.