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

[Remi Forax]

Hi Krys,
why do you need a public API to send the profile to the JIT compiler ?

Rémi

----- Mail original -----
> De: "Krystal Mok" <rednaxelafx at gmail.com>
> À: "Stuart Marks" <stuart.marks at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Mercredi 14 Septembre 2016 02:09:54
> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler

> 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
>>