RFR(s): 4285505: deprecate java.lang.Compiler

[Stuart Marks]

Hi Kris,

Based on your email earlier in this thread, it seemed like you didn't object to 
deprecating j.l.Compiler in Java 9. Since the other respondents were already in 
favor, I've already pushed the changeset. (Sorry.) As things stand, the 
changeset is in the jdk9/dev forest, but it's not in any promoted JDK 9 builds.

If we were to proceed with this as it stands, then the API change in Java SE 9 
visible to programs will merely be the addition of the following annotation to 
java.lang.Compiler:

@Deprecated(since="9", forRemoval=true)

Existing binaries use j.l.Compiler will continue to run, and existing sources 
that use it can still compile, though they will get compilation warnings. The 
earliest release in which java.lang.Compiler would actually be absent is Java SE 
10. There is currently no schedule or project for SE 10, but I would guess that 
it wouldn't ship anytime before mid-2018.

If removal in this time frame is really a problem for Azul, then I suppose this 
deprecation can be revisited and possibly changed in Java SE 9.

But I'm hard pressed to see what value is actually being added by 
java.lang.Compiler that can't be done better by a platform-specific API. You 
mentioned the command() method:

public staticObject <cid:part1.05E042AF.0D7D0BF0 at oracle.com>  command(Object <cid:part1.05E042AF.0D7D0BF0 at oracle.com>  any)

Anything that uses this API is platform-specific. Even if it avoids 
platform-specific types, for example by using String arrays, the values it 
passes and returns are unavoidably platform-specific. Users of this API would be 
better served by using a platform-specific API. Can't Azul create one and 
migrate to it?

s'marks



On 9/13/16 5:09 PM, Krystal Mok wrote:
> Hi OpenJDK developers,
>
> Replying on behalf of Azul Systems:
>
> java.lang.Compiler is an integral part of the current Java SE spec, and is 
> currently being used by multiple independent Java SE implementations of that 
> spec in a spec-conforming way (Azul Zing, Azul Vega, and IBM J9 being concrete 
> exampleS). Before deprecation, a proposed replacement for Java SE 9 would need 
> to be vetted to make sure that is satisfies the needs of current 
> implementations. While JEP165 is a start in that direction, it appears to be 
> very HotSpot specific, and is not written in a specification form (e.g. there 
> is no "If no compiler is available, these methods do nothing." mention).
>
> For example, Azul Zing’s ReadyNow feature makes use of the java.lang.Compiler 
> API to allow applications to pass directives down to the VM, in a similar 
> spirit to what IBM J9 does with the API. We continuously evolve and enrich the 
> commands we support in the API, e.g. in the “Object command(Object)” method, 
> and it would be potentially problematic for us to lose the current API without 
> having a flexible replacement in the Java SE spec.
>
> As such, we suggest that for the time being, java.lang.Compiler should be 
> neither depracated nor removed in Java SE 9. As a practical spec'ed 
> replacement is proposed that will cover the needs of implementations currently 
> using java.lang.Compiler, this can change. Perhaps in the Java SE 10 timeframe.
>
> Thanks,
> Kris (OpenJDK username: kmo)
>
> On Wed, Sep 7, 2016 at 1:52 PM, Stuart Marks <stuart.marks at oracle.com 
> <mailto:stuart.marks at oracle.com>> wrote:
>
>     Hi all,
>
>     Please review this small patch to deprecate java.lang.Compiler for removal.
>
>     Thanks,
>
>     s'marks
>
>     # HG changeset patch
>     # User smarks
>     # Date 1473281459 25200
>     #      Wed Sep 07 13:50:59 2016 -0700
>     # Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d
>     # Parent  76ba1b74f268f1acc4847e242a2cfcd29880418c
>     4285505: deprecate java.lang.Compiler
>     Reviewed-by: XXX
>
>     diff -r 76ba1b74f268 -r e520c4e6970c
>     src/java.base/share/classes/java/lang/Compiler.java
>     --- a/src/java.base/share/classes/java/lang/Compiler.java      Tue Sep 06
>     16:08:54 2016 -0700
>     +++ b/src/java.base/share/classes/java/lang/Compiler.java      Wed Sep 07
>     13:50:59 2016 -0700
>     @@ -1,5 +1,5 @@
>      /*
>     - * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights
>     reserved.
>     + * Copyright (c) 1995, 2016, Oracle and/or its affiliates. All rights
>     reserved.
>       * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>       *
>       * This code is free software; you can redistribute it and/or modify it
>     @@ -29,21 +29,18 @@
>       * The {@code Compiler} class is provided to support Java-to-native-code
>       * compilers and related services. By design, the {@code Compiler} class does
>       * nothing; it serves as a placeholder for a JIT compiler implementation.
>     + * If no compiler is available, these methods do nothing.
>       *
>     - * <p> When the Java Virtual Machine first starts, it determines if the
>     system
>     - * property {@code java.compiler} exists. (System properties are accessible
>     - * through {@link System#getProperty(String)} and {@link
>     - * System#getProperty(String, String)}.  If so, it is assumed to be the
>     name of
>     - * a library (with a platform-dependent exact location and type); {@link
>     - * System#loadLibrary} is called to load that library. If this loading
>     - * succeeds, the function named {@code java_lang_Compiler_start()} in that
>     - * library is called.
>     - *
>     - * <p> If no compiler is available, these methods do nothing.
>     + * @deprecated 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.
>       *
>       * @author  Frank Yellin
>       * @since   1.0
>       */
>     + at Deprecated(since="9", forRemoval=true)
>      public final class Compiler  {
>          private Compiler() {}               // don't make instances
>
>