JDK-6822637 : ResolveError hierarchy needs to be refactored
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: unknown
  • Submitted: 2009-03-26
  • Updated: 2011-07-25
  • Resolved: 2011-07-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b64Fixed
Related Reports
Relates :  
JDK-5088624 - cannot find symbol message should be more intelligent
Description
There are few areas in Resolve.java that need some cleanup. In fact, when overload resolution was first implemented in gjc there was no support for autoboxing, enums, varargs - in other words, overload resolution was a lot easier than it is now. 

Today Resolve has become more complex (overload resolution done in 3-step process) and the main reason for which resolution diagnostic look so outdated is that the diagnostic-related part of Resolve.java hasn't really been restructured in order to accomodate the new changes in method resolution (coming from other JSRs).

Just a snapshot of the current situation:

we have 5 kinds of symbol we might want to resolve:

-VARIABLE
-TYPE
-METHOD
-CONSTRUCTOR
-OPERATOR 


and we have 3 possible outcomes for resolution

-SYMBOL NOT FOUND
-WRONG SYMBOL FOUND
-MANY WRONG SYMBOLS FOUND

With a simple calculation it seems like we'd need to be able to deal with 15 possible error conditions (well some of them aren't really valid, as [FIELD, MANY WRONG SYMBOLS FOUND] - but you got the idea].

In Resolve.java error messages are generated by means of ResolveError and its subclasses - where each subclass is meant to represent a different error category.

-ResolveError extends Symbol
-AccessError extends ResolveError
-AmbiguityError extends ResolveError
-StaticError extends ResolveError

All the 15 erroneous conditions above are mapped into the very same ResolveError base class - in other words the hierarchy of erroneous symbols is highly unbalanced. ResolveError has a lot of stuff to do when a diagnostic is to be generated, while other classes are significantly simpler. This is bad because (i) ResolveError is forced to generate high-level error messages that could apply (with slight variations) to all the 15 cases listed above.

Because of this design problem, any work on resolution diagnostic is likely to be hard (see 5088624).
Comments
SUGGESTED FIX A webrev of this fix is available at the following URL http://hg.openjdk.java.net/jdk7/tl/langtools/rev/18e0269f25e3
24-06-2009
EVALUATION The first logical step is to split ResolveError into an abstract class (named ResolveError) and 3 different subclasses: -SymbolNotFoundError -InapplicableSymbolError -InapplicableSymbolsError (note the plural!) An additional optimization is that we could rewrite the ResolveError.report() method so that, instead of reporting a diagnostic directly to Log, it could instead return a diagnostic corresponding to a given resolution error. This turns out to be a nice feature to have when we need to embed multiple resolution diagnostic into a single multiline diagnostic (see 5088624)
26-03-2009