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

[Krystal Mok]

Hi Stuart,

Again, replying on behalf of Azul Systems:

Removal is the real concern. We can probably live with deprecation (if this
amounts to annotation) as long as removal does not occur until a vetted
alternative is in place. But we suggest a re-consideration of the
deprecation issue if it's driver is an intent to move the functionality to
platform specific classes. We think such a move would be a mistake. While
it is true that we did not flag this earlier, thinking through the issues
around removal of this API and moving it to a platform specific namespace,
and the resulting implications for code portability between JDK
implementations has made us reconsider the issue.

To address the the platform specific questions: A "common home" is very
much needed for the platform specific stuff that controls compiler
behavior, and this common home belongs in the common class namespace [it
currently lives in java.lang.Compiler]. Specifically, we strongly believe
that control of compiler behavior should not require the use and reliance
on platform specific classes. This allows portability of Java code across
Java SE implementations, with [optional] platform specific commands that
may be used by a Java program, and that may differ in choice between target
platforms based on discovery, but that do not require any use of platform
specific classes that do not exist in all compliant JREs. This portability
is key. Note that to date, both Zing and Vega have managed to avoid
exposing ANY platform specific control APIs in the form of
platform-specific classes, and we would like to keep it that way. We have
succeeded at leveraging the generic APIs available is the spec'ed Java SE
platform for control and monitoring purposes. The portability this affords
means that people don't write and deploy Zing-specific and
works-only-on-Zing Java code. This quality is important for us and for
others to maintain.

To be specific about how java.lang.Compiler.command is important (as
opposed to com.azul.zing.Compiler.command) in this context: Current Java
code, which can be build and run using any Java SE compliant JRE, can
currently check the JVM vendor and version (using e.g.
java.lang.management.RuntimeMXBean), and based on what it finds issue
specific compiler control commands using java.lang.Compiler.command. This
is a real, current, and common use case for our JDK. Since no platform
specific classes are used, this Java code remains portable, can be compiled
and tested using any compliant JDK, and runs and resolves completely on any
complaint JRE. If we were to replace java.lang.Compiler.command with
platform specific classes that control compiler behavior, it would make
Java code that would attempt to leverage them non-portable, would limit the
code using the features to compile and test only on JDKs that included
platform specific features, and would prevent using it (or make it more
cumbersome to use) on JREs that did not include the platform specific
classes. [And yes, while there are cumbersome alternatives that would
involve reflection based class discovery, the code for doing that while
remaining portable becomes very "ugly" on the user side].

The JDK is full of common namespace areas that are meant to expose platform
specific behaviors in a portable way. The java.lang.management package is
full of examples of this, and we certainly hope that we are not trending
towards deprecating those with an intent to remove them.

So to summarize: java.lang.Compiler.command is a key API for functionality
that we currently use, and that we leverage and need to remain in the
common (non platform specific) name space. While we can live with
deprecation as part of an API cleanup, this cleanup should result in a
suitable replacement API, and we would want a
non-platform-specific-namespace replacement to exist before the current API
is actually removed at any future date.

Best regards,
Kris (OpenJDK username: kmo)

On Wed, Sep 14, 2016 at 10:18 AM, Stuart Marks <stuart.marks at oracle.com>
wrote:

> 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 static Object <?ui=2&ik=11acc15a9f&view=fimg&th=15729b5219aba842&attid=0.1.1&disp=emb&attbid=ANGjdJ_-R5ZGqJqdnbpCcsnU4V6YlF0MyhWp9OePuUOVLAye-ceOqJCFPQ8ELkgnE7QCqVgW-dp1avpoBBAiKK5iAQZqxmWqwCFcfinOk9PhniOYXtVCkEEiSPS7mwA&sz=s0-l75-ft&ats=1473968449390&rm=15729b5219aba842&zw&atsh=0> command(Object <?ui=2&ik=11acc15a9f&view=fimg&th=15729b5219aba842&attid=0.1.1&disp=emb&attbid=ANGjdJ8YYVCo2zMbI07HPUpHgzFvtmDnozAD0VZsr5Tc_O-oOjyyagMZsEcsnZxRBj8tctWu00RPqlcoaUZ-iUk9xDEZaZuV77luGEI6V6b3g-572jZtfbVUQd7178g&sz=s0-l75-ft&ats=1473968449390&rm=15729b5219aba842&zw&atsh=0> 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>
> 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/ja
>> va/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
>>
>>
>
>