|
Quick Lists
|
|
Bug ID:
|
6799605
|
|
Votes
|
0
|
|
Synopsis
|
Basic/Raw formatters should use type/symbol printer instead of toString()
|
|
Category
|
java:compiler
|
|
Reported Against
|
|
|
Release Fixed
|
7(b51)
|
|
State
|
10-Fix Delivered,
request for enhancement
|
|
Priority:
|
3-Medium
|
|
Related Bugs
|
6369605
,
6492019
,
6735840
|
|
Submit Date
|
30-JAN-2009
|
|
Description
|
After the fix of 6735840 we have new types/ customer 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 customer 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
Posted Date : 2009-01-30 17:00:22.0
|
|
Work Around
|
N/A
|
|
Evaluation
|
Will do
Posted Date : 2009-01-30 17:00:22.0
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |