JDK-4071299 : Compilation spec needed: should state if private should imply final for a method
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 1.1.3
  • Priority: P4
  • Status: Closed
  • Resolution: Future Project
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1997-08-12
  • Updated: 2010-08-21
  • Resolved: 2010-08-21
Related Reports
Relates :  
JDK-4421728 - Specification required for mapping from class names to file names
Relates :  
JDK-4208592 - (reflect) Methods to distinguish implicitly vs. explicitly final methods
Relates :  
JDK-4396587 - "A private method and all methods declared in a final class are final"
Description

Name: tb29552			Date: 08/12/97


Reported by:
company - Sybase Waterloo , email - ###@###.###

class bug52 {
    private String foo() {
        return null;
    }
};

The classfile generated for this source code
doesn't have the final attribute set for
method bug52.foo.  This is incorrect according
to the JLS 8.4.3.3 where it states that a
private method is implicitly final.
======================================================================
Comments
WORK AROUND Name: tb29552 Date: 08/12/97 Explicitly add the final modifier. ======================================================================
11-06-2004
EVALUATION This sentence of the JLS might indeed be interpreted as suggesting that the final bit always be set if the private bit is set. However, the VM spec does not state this, and a quick poll of VM engineers indicates that it does not matter one way or the other to either existing VM. A reason to *not* set the bit is to allow more accurate decompilation; always setting the bit for final will throw away information (albeit useless information.) I recommend that a sentence be added to the VM spec to state that the the final bit need not be set if the private bit is set, to make this interpretation crystal clear. david.stoutamire@Eng 1997-08-12 The JLS semantics are satisfied by implementations as they stand, since private methods cannot be overridden. The JVMs does not care. Reflection shows whatever the class file says. None of these specs need modification,so there is no spec bug. Rather, this should be addressed by a new spec, determining how Java to JVM compilation should work. As such, this an RFE, not a bug. gilad.bracha@eng 2000-03-10
10-03-2000