JDK-5043991 : (spec) java.compiler related inconsistency between implementation and docs
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 5.0u5,6
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2004-05-07
  • Updated: 2024-04-12
Related Reports
Duplicate :  
JDK-6356262 - java.compiler key does not show up by using getProperties() in 5.0
Relates :  
JDK-6334530 - (spec) Some System.getProperties keys undocumented
Relates :  
JDK-8041676 - remove the java.compiler system property
Relates :  
JDK-8017116 - Deprecate java.lang.Compiler
Relates :  
JDK-6374661 - JDI: Obsolete reference to java.compiler should be removed
Description
The 1.5.0 javadoc for java.lang.System states:

  The current set of system properties for use by the getProperty(String)
  method is returned as a Properties object.  If there is no current set
  of system properties, a set of system properties is first created and
  initialized.  This set of system properties always includes values for
  the following keys: ...

And among the keys listed is java.compiler.  The above statement thus
quite clearly claims that a value for java.compiler always should
be included.

However, when executing a small program that lists the system
properties (see attachment), java.compiler is lacking when using
1.5.0.  Further, the 1.5.0 javadoc for java.lang.Compiler states:

  When the Java Virtual Machine first starts, it determines if the system
  property java.compiler exists.  (System properties are accessible through
  getProperty and , a method defined by the System class.)  If so, it is
  assumed to be the name of a library ...

I interpret this as "sometimes the system property java.compiler could
be missing".

So, in addition to aforementioned discrepancy between implementation and
documentation, there also appears to be a discrepancy (contradiction)
within the documentation itself.
Comments
[~smarks] just stumbled across this one so assigned to you.
21-03-2023
SUGGESTED FIX 1) CR 6374661 calls for removal of the JDI code dealing with the java.compiler property or a comment explaining that Sun's Java SE implementation no longer uses this property. 2) This bug's fix can add a comment to the java/awt/Toolkit refs to Compiler to explain that with Sun's Java SE implementation the enable/disable are null operations and the calls are on left in place in case a licensee might need them. There are already comments in the Sun JVM code making it clear that enable/disable is not supported. If JVM warnings are enabled a message is output for each enable/disable indicating it is not supported but otherwise it's a silent, null operation. 3) Ditto for the Compile class source code comments. 4) The Compiler class javadoc can be updated via Sun change process. The Compiler doc currently says "If no compiler is available, these methods do nothing" and this should be clarified to mean "available for implementation" so folks won't think that as they know a compiler is present this interface must be available. That is, Hotspot has one or more compilers, but none are available as implementations of Compiler's methods. An additional sentence saying that a value assigned to java.compiler will have no effect (if no implementation is available) would be helpful. 5) The java.compiler property javadoc in System.getProperties just says "Name of JIT compiler to use." A change to add something along the lines of "(may be ignored)" is probably the best we can do to clarify the situation while avoiding conflict with implementations that do offer support for the property.
23-01-2006
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
27-06-2004
PUBLIC COMMENTS -
27-06-2004
EVALUATION It appears that the last time that we set the system property java.compiler (the name of the JIT compiler) was set was in 1.2.2. -- iag@sfbay 2004-05-12 To my knowledge, support for the "java.compiler" system property in J2SE 5.0 (Tiger) implementations is optional, i.e., it is not a compatibility requirement. As far as I know, the "java.compiler" property was only meaningful in our earlier JDK releases (pre-1.4) which included the Classic VM (now EOL'd); it could be used to specify a JIT compiler that works with the Classic VM. However, when we switched to the HotSpot VM, this property was being maintained just for compatibility reasons; the HotSpot VM simply ignores it. I think a correction to the documentation would fix this bug. Carlos.Lucasius@Canada 2004-05-12 Probably we should simply remove the documentation of this system property from the spec of System.getProperty. However, there are still users of the java.lang.Compiler API within the JDK, e.g. ./awt/Toolkit.java:802: java.lang.Compiler.disable(); ./awt/Toolkit.java:850: java.lang.Compiler.enable(); and it would be good to understand how much we could delete (ideally all of it). It's too late for Tiger; let's fix it for Mustang. ###@###.### 2004-06-26
26-06-2004