JDK-4208592 : (reflect) Methods to distinguish implicitly vs. explicitly final methods
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Affected Version: 1.1.6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_95
  • CPU: x86
  • Submitted: 1999-02-04
  • Updated: 2012-09-28
Related Reports
Relates :  
JDK-4396587 - "A private method and all methods declared in a final class are final"
Relates :  
JDK-4071299 - Compilation spec needed: should state if private should imply final for a method
Description

Name: dbT83986			Date: 02/03/99


in a final class, all methods are implicitly
final, yet reflection does not label them as such.

i was of the understanding (and i think it's in
JLS somewhere) that specifying a method as final
in a final class has no effect. however, this prints
out false

public final class p {
  public void thing() { }
  public static void main(String[] args) throws Throwable {
    System.out.println(java.lang.reflect.Modifier.isFinal(
         p.class.getMethod("thing", new Class[0]).getModifiers()
    ));
  }
}

whereas declaring thing() to be final causes the
output to be "true". Is this as intended?
(Review ID: 39440)
======================================================================
Comments
EVALUATION I agree with the previous evaluation that "the only plausible thing would be to state rules compatible with current practice. That is, the bits reflect the source code." Such rules belong in a compilation spec, the need for which is noted elsewhere (4071299, which also happens to deal with ACC_FINAL). In any case, the distinction between implicitly and explicitly final methods remains. An SDN comment suggested a Method.getImpliedModifiers() which would make no such distinction.
24-09-2007
WORK AROUND Name: dbT83986 Date: 02/03/99 explicitly declare all methods in final classes as final(?) ======================================================================
11-06-2004
PUBLIC COMMENTS If a method is declared explicitly final, then its final bit must be set in the class file. If it is implicitly final, then the bit should not be set.
10-06-2004
EVALUATION Reflection is simpy reporting the bits set in the class file. The question is how to compiler should set them. JLS 8.4.3.3 doesn't pin this down. What about the VM spec? william.maddox@Eng 1999-02-10 In general, we set the modifier bits in the class files to correspond to modifiers that are implicitly present according to the language spec, however, the VM spec does not require this uniformly. Historically, this was not done for the implicitly-final methods of final classes. The fact that a final class cannot be subclassed at all logically implies that none of its methods can be overridden, which is precisely what it means to be final according to the JLS. The correspondence between such language notions and actual bits in the class file is the purview of the VM spec, which remains silent. An attempt to rationalize the treatment of implicit modifiers by consistently setting the bits (as required, for example for the ACC_ABSTRACT bit of interfaces, which are implicitly abstract) was made and later retracted because it broke serialization compatibility. It can be argued that reflection should give a view of the program based purely on the source-language semantics, thus there should be no observable distinction between a method that is explicitly or implicitly final. Nonetheless, the reflection design never got this right, and changing it would have implications for serialization. I would hope that we could resolve this mess in a clean and consistent fashion, but it is a complicated specification issue that cannot be addressed by the compiler alone, and the small improvement in elegance is most likely not worth the real-world pain of a fix. william.maddox@Eng 2000-01-04 Reflection reports on the bits as seen in the class file. No specific rules are defined for how to compile these bits when the class is final but the method is not. One can make the argument that a policy is stated - the ACC_FINAL bit means that a method is "Declared final", which to my mind implies an explicit declaration. This is also current practice. But this is debatable at best. At this point, the only plausible thing would be to state rules compatible with current practice. That is, the bits reflect the source code. From that viewpoint, the bug is in that we do not state a policy clearly. gilad.bracha@eng 2000-01-04
04-01-2000