Bugzilla – Full Text Bug Listing
| Summary: | Enum methods "values" and "valueOf" are not marked as synthetic | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Theodora Yeung <tyeung> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | markus.kell.r |
| Version: | 3.1 | ||
| Target Milestone: | 3.1 M6 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Theodora Yeung
This would be trivial to add. Though these are generated methods, neither the JLS or Javac consider theem as synthetic. Will not change our behavior unless proven wrong. The JVM specs say: The Synthetic attribute6 is a fixed-length attribute in the attributes table of ClassFile (§4.2), field_info (§4.6), and method_info (§4.7) structures. A class member that does not appear in the source code must be marked using a Synthetic attribute, or else it must have its ACC_SYNTHETIC bit set. The only exceptions to this requirement are for default constructors and the class initialization method. But at a different location it says: A class may be marked with the ACC_SYNTHETIC flag to indicate that it was generated by the compiler and does not appear in the source code. So on one side we have "must be marked" and on the other side "may be marked". This is clearly not the same meaning. I also wish these were consistent. Interestingly the enum $values field is tagged by both javac and us as synthetic. In this very case, these methods are not coming from anywhere, they are overriding Enum methods, and are part of the protocol. One could argue that overriding an API method with a synthetic one feels a bit inconsistent... closing for now |