RFR: 8205129: Remove java.lang.Compiler

[David Holmes]

On Mon, 20 Mar 2023 17:35:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> I don't know how much interdependency there is between the java.compiler system property and the java.lang.Compiler class. 
> On the library side I think they're independent.

That may be true today but originally they were very much inter-dependent:

/**
 * The <code>Compiler</code> class is provided to support
 * Java-to-native-code compilers and related services. By design, the
 * <code>Compiler</code> class does nothing; it serves as a
 * placeholder for a JIT compiler implementation.
 * <p>
 * When the Java Virtual Machine first starts, it determines if the
 * system property <code>java.compiler</code> exists. (System
 * properties are accessible through <code>getProperty</code>  and ,
 * a method defined by the <code>System</code> class.) If so, it is
 * assumed to be the name of a library (with a platform-dependent
 * exact location and type); the <code>loadLibrary</code> method in
 * class <code>System</code> is called to load that library. If this
 * loading succeeds, the function named
 * <code>java_lang_Compiler_start()</code> in that library is called.
 * <p>
 * If no compiler is available, these methods do nothing.

The only part of that we have left today is that `-Djava.compiler=NONE` is an alias for `-Xint` mode.

JDK 9 effectively severed the class from the property by removing the above wording, so in that sense the two issues can be addressed separately. We should have handled the property deprecation back in JDK 9 too (not that there is an actual definition/process of deprecating system properties).

P.S I will try not to take any vacation until after this is resolved. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13092#issuecomment-1477170195