The submitter's observations are correct; the bit positions used for bridge and volatile are the same. The getModifiers method (roughly) returns the class file access_flag field for the structure in question (class, field, method, constructor). At the vm level, the access_flag field is only 16 bits wide. With the existing modifiers and the new modifiers introduced in Tiger, there are more than 16 options so some collisions were unavoidable unless that aspect of the class file were changed. It is too late in Tiger to modify that aspect of the class file specificatation. One way for this problem to be addressed would be to add methods like "toMethodString" and "toFieldString" to the Modifier class so that only the modifiers appropriate for that kind of member would be printed; in other words, the new methods would allow "volatile" and "bridge" to be disambiguated.
Addressing JDC comments on this bug's initial evaluation, this bug is related to a number of aspects of the core reflection design. First, it is not always very clear whether core reflection is modeling jvm semantics of Java language semantics. The two are distinct and the right answer depends on what is being modeled. In some cases, like this one, the core reflection implementation returns the class file view. Yes, it is true that Method.getModifiers could screen out the "unwanted" bits; but that information is needed in some circumstances. Since the Modifier class does not know where the modifier set is coming from, it cannot do this screening itself. It would be reasonable to update the JavaDoc of the getModifier method to more accurately describe what it does.
###@###.### 2005-1-25 00:20:52 GMT