JDK-6799605 : Basic/Raw formatters should use type/symbol printer instead of toString()
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: unknown
  • Submitted: 2009-01-30
  • Updated: 2013-07-18
  • Resolved: 2012-01-13
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 b51Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
After the fix of 6735840 we have new types/symbol visitor printer in Types. Those visitors could be refined by current diagnostic formatters in order to provide better diagnostic output. In particular, they could help in improving:

*) localization support - as the visitors have full support for localized output
*) improving wildcards diagnostics

The latter point it's quite intruguing as wildcards-related diagnostics have always been quite hard to grasp for the average programmer - in the first place it would be good at least to generate a more user-friendly numeric identifier for captured-type variables, instead of relying on Object.hashcode(). Note that the actual output for captured type-variables severely limits the predictability of error messages containing captured types (because hash always changes!). This makes it almost impossible to write e.g. a simple negative regression test that compares the output of the compiler against a golden file.

Another problem is that the current output for captured type-variables might go into an endless loop if the bound of the captured type variables contains the variable itself; e.g. 

#420-captureof ? extends Enum<#420-captureof ... >

This poses serious issues when generating more complex type-system diagnostics - note that this situation is very rare but it's actually needed by another type-system fix - see 6369605

Comments
SUGGESTED FIX A webrev of this fix is available at the following URL http://hg.openjdk.java.net/jdk7/tl/langtools/rev/86b60aa941c6
05-03-2009

EVALUATION Will do
30-01-2009