JDK-8304458 : Remove java.lang.Compiler
  • Type: CSR
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 21
  • Submitted: 2023-03-19
  • Updated: 2023-04-10
  • Resolved: 2023-03-28
Related Reports
CSR :  
Relates :  
Description
Summary
-------

The class java.lang.Compiler has been non-functional for a long time. It was terminally deprecated in Java 9.  Time has come to remove it.

Problem
-------
JDK-4285505 summarizes the problem like this: 

> The class java.lang.Compiler supposedly provides a high level
> reflective interface to the underlying JIT. This interface is
> effectively ignored by Hotspot, and by many other implementations.
> 
> We have long ago abandoned efforts for a standaradized JIT interface.
> JITs and their technologies vary too widely. At the user level, it is
> unclear why control of a quality-of-implementation factor like a JIT
> needs to be available in a portable form.

The @deprecated notice in the Javadocs of the class states:

> JIT compilers and their technologies vary too widely to be controlled
> effectively by a standardized interface. As such, many JIT compiler
> implementations ignore this interface, and are instead controllable by
> implementation-specific mechanisms such as command-line options. This
> class is subject to removal in a future version of Java SE.

A search in a large corpus of Java code indicates that the class is very rarely used:

> A search of 3M classes in 130k artifacts found just 8 references to this class. 6 of the 8 are versions of the same thing seem to be an off-label usage in a class named net.openhft.chronicle.core.Jvm where it calls Compiler.enable() instead of Thread.onSpinWait on older JDK releases.

Solution
-------
Remove the class java.lang.Compiler. This class has no use or references within OpenJDK.


Specification
-------
Remove the following class:

java.lang.Compiler

Comments
> Per comments in the PR, please link to any follow-up bugs to remove java.compiler support. The issue for the PR (JDK-8205129) already links to JDK-8041676 (deprecate the java.compiler system property for removal). I have added a link to JDK-8041676 in this issue as well. I have a feeling I may have misunderstood your comment, Joe. Please advice if this makes no sense to you :-)
29-03-2023

Moving to Approved. Per comments in the PR, please link to any follow-up bugs to remove java.compiler support.
28-03-2023

It's a general process note explaining the need for an accurate value of "Scope". The updates to the JSR are triggered by the revised Scope.
21-03-2023

[~iris] > Assuming this CSR is approved, the removal needs to be added to the "APIs removed" section of JSR 396 (Java SE 21). Is any action expected on my part as a contributor to make sure this happens, or was this more of a "note to self"?
21-03-2023

Removing this will avoid new developers stumbling on it. A good change for early in JDK 21 in case other VM implementers (J9, Azul) bring new insights that would justify bringing it back.
21-03-2023

Definitely time this anachronism was removed.
21-03-2023

Moving to Provisional, not Approved. [~eirbjo], please request one or more engineers review the CSR before it is Finalized for the second phase of CSR review.
21-03-2023

Scope updated to "SE" since java.lang.Complier is an SE API. Assuming this CSR is approved, the removal needs to be added to the "APIs removed" section of JSR 396 (Java SE 21).
20-03-2023