JDK-7077364 : (javac) Starting positions of ClassTree for enum constants
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2011-08-10
  • Updated: 2017-07-11
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.
Other
tbd_majorUnresolved
Related Reports
Relates :  
Description
Consider the following code:
enum Test {
    A {};
}

The "A {}" is modeled as a field whose initializer is a NewClassTree, containing a ClassTree as its ClassBody. Currently, the NewClassTree's starting position is:
    A {};
      ^
but the embedded ClassTree's position is:
    A {};
    ^

Which confuses the NetBeans code generator, as the inner tree is outside the bounds of the outer tree. I propose this position is changed to:
    A {};
      ^

Similarly for enum constants with parameters, the NewClassTree's position would be kept as
    A (1) {};
      ^
and the ClassTree's position would be:
    A (1) {};
          ^

Comments
This issue should also be addressed along with JDK-8024098
11-07-2017

See the recent proposals (again) for new tree nodes for enum constants.
06-07-2017

This needs to be checked with Jan Lahoda first.
02-04-2014

I am going to drop this to P5, to stay under the radar for a while, until we know what needs to be done.
26-04-2013

Comment from Jan Lahoda through email: Thanks for looking at that. It can definitely wait. Actually I think Dusan was recently doing some change in close proximity, so it may be a good idea to wait some time anyway to see if the recent change does not introduce new problems and the re-evaluate if the assertions in the bug still hold.
26-04-2013

SUGGESTED FIX attached diff.
10-08-2011