JDK-8041676 : remove the java.compiler system property
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-04-24
  • Updated: 2023-08-09
  • Resolved: 2023-04-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 21
21 b20Fixed
Related Reports
Blocks :  
JDK-8022854 - System.setProperties(null) does not remove implementation properties
CSR :  
JDK-8305998 - remove the java.compiler system property
Duplicate :  
JDK-8017115 - Remove java.compiler from System.getProperties() documentation
Duplicate :  
JDK-8225772 - Spec Clarification : System:getProperties() not listing the "java.compiler"
Relates :  
JDK-5043991 - (spec) java.compiler related inconsistency between implementation and docs
Relates :  
JDK-8304458 - Remove java.lang.Compiler
Relates :  
JDK-8205129 - Remove java.lang.Compiler
Relates :  
JDK-4285505 - deprecate java.lang.Compiler
Sub Tasks
JDK-8306649 :  
Release Note: Removal of `java.compiler` System Property - Resolved
Description
The java.compiler property is mentioned in System.getProperties(). It simply says

    java.compiler     Name of JIT compiler to use

This should be deprecated for removal.

The java.compiler property value of "none" is treated by Hotspot as a synonym for -Xint. This behavior is still active, so if this property is deprecated, perhaps a warning message should be issued before removing it. Then again, lots of things still do -Djava.compiler=none to run in interpretive mode, so it's unclear whether removing this is worth it. Perhaps it should be defined so that "none" (case insensitive) means interpretive mode, and other values are undefined or implementation-specific.
Comments
Changeset: b8f0a668 Author: Jaikiran Pai <jpai@openjdk.org> Date: 2023-04-20 01:49:31 +0000 URL: https://git.openjdk.org/jdk/commit/b8f0a668dd69b831d9f0e617ac3cb65830f69909
20-04-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13475 Date: 2023-04-14 12:19:41 +0000
14-04-2023
> Hello Eirik, I have changes related to this, which I've been testing the past couple of days. That's great, thanks!
13-04-2023
Hello Eirik, I have changes related to this, which I've been testing the past couple of days.
13-04-2023
I'd like to do a PR for the solution described in Alan's 2023-04-11 comment: - Drop java.compiler from System.properties - In arguments.h, arguments.cpp, leave just a warning that -Djava.compiler is ignored and -XInt should be used instead. Would it be ok to repurpose this issue for this task, or would it be better to create a new issue and link to this one?
13-04-2023
The simplest thing is to drop java.compiler from the list of standard properties documented in System.properties, and remove remnants from the HotSpot code. I don't expect there are many production deployments running with just the interpreter, and even if they are, why would they run with -Djava.compiler=NONE instead of -Xint? I think the suggestion of deprecation and/or warning is for scripts running with -Djava.compiler=NONE and -Xrunjdwp that probably pre-date full speed debugging or where the options were copied from old documentation. A warning that the system property is ignored and use -Xint for interpreter might be enough - it doesn't seem worth having one release printing a warning message says that -Djava.compiler=NONE will be ignored in a future release, then some future release changing it again.
11-04-2023
I don't think there is a precedent for deprecating a system property. Given hotspot processes this particular property I would suggest that upon deprecation hotspot issues its own deprecation warning as-if it were a -XX flag. I can coordinate with you on that part but I'll be on vacation until the 22nd.
04-07-2019
I was going to propose that we simply rip this out, but it looks like it actually has some effect. Most processing occurs in src/hotspot/share/runtime/arguments.{cpp,hpp} where setting the property to empty or NONE seems equivalent to -Xint. Regardless, it actually has behavior, so we probably should following the protocol of deprecating this for removal prior to removing it. There's no API for this, but the doc in System.getProperties() should be updated to mention the deprecation. I can't find any other mentions in documentation, but if there are any, they should be updated too. [~dholmes] Should Hotspot issue a warning message, or should this be a doc-only change?
04-07-2019
Lets bump this up and finally get this deprecated and then removed. Djava.compiler has not been used to select a JIT since pre-hotspot days (classic VM on Windows could use it to select symantec JIT) and the value "NONE" to mean "run the interpreter" is an anachronism. It also ties into the -Xdebug flag anachronism (see JDK-8227229). Also note that JDI still refers to this too: src/jdk.jdi/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java if ((options.indexOf("-Djava.compiler=") != -1) && (options.toLowerCase().indexOf("-djava.compiler=none") == -1)) { throw new IllegalConnectorArgumentsException("Cannot debug with a JIT compiler", ARG_OPTIONS); }
04-07-2019
I'm repurposing this bug. Previous text was ========== Summary: java.compiler property is uninitialized Description: Under hotspot the property is undefined contrary to of System.getProperties() ========== As far as I can see, the java.compiler property is intended to be set by the invoker of the JVM, at invocation time (e.g., from the command line). It's not intended to be set by anything in the system. The spec of the java.lang.Compiler property implies that the value of this property is used for loading a JIT from a named, native library. This hasn't been true for a very, very long time (if it was ever true at all). This text has been removed by JDK-4285505. Quick investigation reveals one place in the code that uses this property. In hotspot/src/share/vm/runtime/arguments.cpp the value of "none" is treated as a synonym for -Xint. This code is still active at the time of this writing. There are a bunch of occurrences of "-Djava.compiler=none" in check-in NB projects, tests, and demos. It's unclear whether these are still necessary.
09-09-2016
The apidoc for java.lang.compiler implies that the property need not exist. If it does exist, then its value is supposed to be the name of the JIT library. So, hotspot by not initializing the property means it doesn't provide a JIT.
25-04-2014
See also JDK-4285505, the long standing bug to deprecate java.lang.Compiler.
24-04-2014
I did some research on java.compiler and the java.lang.Compiler class. The IBM VM supports the interface and both the java.compiler and java.vm.info properties
24-04-2014
The java.compiler property is legacy and maybe it's finally time to just drop it.
24-04-2014