Re: 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 
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 proble

Re: 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   command(Object 
  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 > 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.
  *
- *  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)

Re: 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" 
> À: "Stuart Marks" 
> Cc: "core-libs-dev" 
> 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 
> 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.
>>   *
>> - *  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.
>> - *
>> - *  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
>>   */
>> +@Deprecated(since="9", forRemoval=true)
>>  public final class Compiler  {
>>  private Compiler() {}   // don't make instances
>>

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

[Krystal Mok]

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 
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.
>   *
> - *  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.
> - *
> - *  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
>   */
> +@Deprecated(since="9", forRemoval=true)
>  public final class Compiler  {
>  private Compiler() {}   // don't make instances
>
>

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

[Stuart Marks]

Hi Roger,

Thanks for mentioning bug JDK-8041676.

As far as I understand, the java.compiler property is intended to be set by the 
user in order to tell the JVM which JIT compiler to use. This is hinted at in 
the text I'm removing from the java.lang.Compiler spec in this changeset.


The java.compiler property is also mentioned in j.l.System.getProperties(), 
where it simply says


java.compiler Name of JIT compiler to use

which is pretty inconclusive.

Bug JDK-8041676 is strange in that it implies that something in the JDK should 
be setting this property. But I think that's wrong.


I did a quick survey, and there are bunch of places that set 
-Djava.compiler=none in test code, demos, and in various checked-in NetBeans 
projects, but the only place that seems to read it is 
hotspot/src/share/vm/runtime/arguments.cpp where the specific value of "none" 
for this property is treated as a synonym for -Xint (run in interpretive mode). 
This still seems to be active.


I'll update JDK-8041676 with these findings. I don't think java.lang.Compiler 
deprecation has any impact on the java.compiler property, though, except to 
remove some long-obsolete text.


s'marks



On 9/9/16 6:55 AM, Roger Riggs wrote:

Hi Stuart,

Related to java.lang.Complier there is the System property "java.compiler" [1].
Is there some notation needed on the property or will it just go poof when the
compiler is removed?

Thanks, Roger

[1] JDK-8041676  java.compiler
property is uninitialized


On 9/7/2016 4:52 PM, Stuart Marks 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.javaTue Sep 06
16:08:54 2016 -0700
+++ b/src/java.base/share/classes/java/lang/Compiler.javaWed 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.
  *
- *  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.
- *
- *  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
  */
+@Deprecated(since="9", forRemoval=true)
 public final class Compiler  {
 private Compiler() {}   // don't make instances

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

[Roger Riggs]

Hi Stuart,

Related to java.lang.Complier there is the System property 
"java.compiler" [1].
Is there some notation needed on the property or will it just go poof 
when the compiler is removed?


Thanks, Roger

[1] JDK-8041676  
java.compiler property is uninitialized



On 9/7/2016 4:52 PM, Stuart Marks 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.javaTue Sep 
06 16:08:54 2016 -0700
+++ b/src/java.base/share/classes/java/lang/Compiler.javaWed 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.
  *
- *  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.
- *
- *  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
  */
+@Deprecated(since="9", forRemoval=true)
 public final class Compiler  {
 private Compiler() {}   // don't make instances

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

[Tim Ellison]

On 08/09/16 17:08, Krystal Mok wrote:
> Thanks for your reply. It's good to know at least the known use cases
> from IBM have indeed been discussed.
> 
> On Thu, Sep 8, 2016 at 9:01 AM, Tim Ellison  <mailto:t.p.elli...@gmail.com>> wrote:
> 
> On 07/09/16 23:45, Krystal Mok wrote:
> > I see that on the JBS page, your most recent comment says it's been 
> decided
> > that for JDK9 it's okay to deprecate and forRemoval=true, while also
> > mentioning the uses of this class in IBM's implementation.
> >
> > Does that mean IBM has agreed on the deprecation of this class?
> 
> Yep, I've seen those references and am ok with the deprecation in JDK9.
> 
> > I thought J9 had features that allowed Java applications to do
> > fine-grained control over the JIT compiler at runtime, e.g. force
> > compilation of specified methods *at some certain point* in the
> > program.
> 
> Not sure what you are thinking of there Kris.  We do implement the five
> public methods on Compiler to do pretty much what you would expect:
> 
> java.lang.Compiler.command(Object any) - this only does something for a
> couple of custom arguments, most objects passed to it are simply
> ignored.
> 
> java.lang.Compiler.compileClass(Class clazz) - the JIT will compile
> all methods in the given class. These compilations are synchronous, i.e.
> the application thread that called the API will wait until all
> compilations are finished.
> 
> This and the next one are the ones I was talking about: these calls can
> be made at arbitrary points in time during Java program execution, so
> they are "dynamic".
> For instance, I may have a program that wishes to convey phase shift
> properties to the VM, by calling once of these methods right before the
> phase shift happens. That's something a static configuration means (e.g.
> compiler configuration file) won't be able to do. Ditto for the
> "waitOnCompilationQueue" command.

Yes, that is one way in which we can have an application indicate to the
JIT that it is moving from start-up to run phase, and we have played
with that.  But come JDK9 and beyond there are much better opportunities
for start-up optimizations that means these APIs can be removed without
grief.

Regards,
Tim

> java.lang.Compiler.compileClasses(String s) - the JIT will compile all
> methods from classes that match the given string.
> 
> java.lang.Compiler.disable() - disables all future JIT compilations.
> 
> java.lang.Compiler.enable() - resumes JIT compilations.
> 
> IMO dropping these APIs would not be a great loss.
> 
> > What JEP 165 is proposing can only statically configure JIT behaviors 
> for
> > HotSpot. The same approach doesn't seem to cover what J9 used to 
> support.
> >
> > Could you please share more background on the discussions that led to 
> the
> > decision?
> 
> As you would expect, IBM and Oracle talk regularly about all things
> Java, and this topic was raised as a heads-up that it was coming to
> OpenJDK.  So there really isn't any background to the discussion.
> 
> Regards,
> Tim
> (IBM Java team)
> 
> > On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks
> mailto:stuart.ma...@oracle.com>>
> > wrote:
> >
> >> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler
> >>
> >> :-)
> >>
> >>
> >> On 9/7/16 2:44 PM, Remi Forax wrote:
> >>
> >>> Yes, i like this patch :)
> >>>
> >>> Aleksey, It's worst than what you think because for a lot of people
> >>> Compiler == java compiler and not JIT compiler so they try to
> compile a
> >>> .java file with the method compileClasses(String).
> >>>
> >>> I'm glad this class will disappear soon.
> >>>
> >>> Rémi
> >>>
> >>> - Mail original -
> >>>
> >>>> De: "Aleksey Shipilev"  <mailto:aship...@redhat.com>>
> >>>> À: "Stuart Marks"  <mailto:stuart.ma...@oracle.com>>, "core-libs-dev" <
> >>>> core-libs-dev@openjdk.java.net
> <mailto:core-libs-dev@openjdk.java.net>>
> >>>> Envoyé: Mercredi 7 Septembre 2016 23:34:02
> >>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler
> >>>>
> >>>
> >>> On 09/07/2016 11:52 PM, Stuart Marks wrote:
> >>>>
> >>>>> Please review this small patch to deprecate java.lang.Compiler for
> >>>>> removal.
> >>>>>
> >>>>
> >>>> Yes, +1.
> >>>> This class is very confusing to have these days.
> >>>>
> >>>> -Aleksey
> >>>>
> >>>
> 
> 

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

[Krystal Mok]

Hi Tim,

Thanks for your reply. It's good to know at least the known use cases from
IBM have indeed been discussed.

On Thu, Sep 8, 2016 at 9:01 AM, Tim Ellison  wrote:

> On 07/09/16 23:45, Krystal Mok wrote:
> > I see that on the JBS page, your most recent comment says it's been
> decided
> > that for JDK9 it's okay to deprecate and forRemoval=true, while also
> > mentioning the uses of this class in IBM's implementation.
> >
> > Does that mean IBM has agreed on the deprecation of this class?
>
> Yep, I've seen those references and am ok with the deprecation in JDK9.
>
> > I thought J9 had features that allowed Java applications to do
> > fine-grained control over the JIT compiler at runtime, e.g. force
> > compilation of specified methods *at some certain point* in the
> > program.
>
> Not sure what you are thinking of there Kris.  We do implement the five
> public methods on Compiler to do pretty much what you would expect:
>
> java.lang.Compiler.command(Object any) - this only does something for a
> couple of custom arguments, most objects passed to it are simply ignored.
>
> java.lang.Compiler.compileClass(Class clazz) - the JIT will compile
> all methods in the given class. These compilations are synchronous, i.e.
> the application thread that called the API will wait until all
> compilations are finished.
>
> This and the next one are the ones I was talking about: these calls can be
made at arbitrary points in time during Java program execution, so they are
"dynamic".
For instance, I may have a program that wishes to convey phase shift
properties to the VM, by calling once of these methods right before the
phase shift happens. That's something a static configuration means (e.g.
compiler configuration file) won't be able to do. Ditto for the
"waitOnCompilationQueue" command.

Thanks,
Kris


> java.lang.Compiler.compileClasses(String s) - the JIT will compile all
> methods from classes that match the given string.
>
> java.lang.Compiler.disable() - disables all future JIT compilations.
>
> java.lang.Compiler.enable() - resumes JIT compilations.
>
> IMO dropping these APIs would not be a great loss.
>
> > What JEP 165 is proposing can only statically configure JIT behaviors for
> > HotSpot. The same approach doesn't seem to cover what J9 used to support.
> >
> > Could you please share more background on the discussions that led to the
> > decision?
>
> As you would expect, IBM and Oracle talk regularly about all things
> Java, and this topic was raised as a heads-up that it was coming to
> OpenJDK.  So there really isn't any background to the discussion.
>
> Regards,
> Tim
> (IBM Java team)
>
> > On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks 
> > wrote:
> >
> >> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler
> >>
> >> :-)
> >>
> >>
> >> On 9/7/16 2:44 PM, Remi Forax wrote:
> >>
> >>> Yes, i like this patch :)
> >>>
> >>> Aleksey, It's worst than what you think because for a lot of people
> >>> Compiler == java compiler and not JIT compiler so they try to compile a
> >>> .java file with the method compileClasses(String).
> >>>
> >>> I'm glad this class will disappear soon.
> >>>
> >>> Rémi
> >>>
> >>> - Mail original -
> >>>
> >>>> De: "Aleksey Shipilev" 
> >>>> À: "Stuart Marks" , "core-libs-dev" <
> >>>> core-libs-dev@openjdk.java.net>
> >>>> Envoyé: Mercredi 7 Septembre 2016 23:34:02
> >>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler
> >>>>
> >>>
> >>> On 09/07/2016 11:52 PM, Stuart Marks wrote:
> >>>>
> >>>>> Please review this small patch to deprecate java.lang.Compiler for
> >>>>> removal.
> >>>>>
> >>>>
> >>>> Yes, +1.
> >>>> This class is very confusing to have these days.
> >>>>
> >>>> -Aleksey
> >>>>
> >>>
>

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

[Tim Ellison]

On 07/09/16 23:45, Krystal Mok wrote:
> I see that on the JBS page, your most recent comment says it's been decided
> that for JDK9 it's okay to deprecate and forRemoval=true, while also
> mentioning the uses of this class in IBM's implementation.
> 
> Does that mean IBM has agreed on the deprecation of this class?

Yep, I've seen those references and am ok with the deprecation in JDK9.

> I thought J9 had features that allowed Java applications to do 
> fine-grained control over the JIT compiler at runtime, e.g. force
> compilation of specified methods *at some certain point* in the
> program.

Not sure what you are thinking of there Kris.  We do implement the five
public methods on Compiler to do pretty much what you would expect:

java.lang.Compiler.command(Object any) - this only does something for a
couple of custom arguments, most objects passed to it are simply ignored.

java.lang.Compiler.compileClass(Class clazz) - the JIT will compile
all methods in the given class. These compilations are synchronous, i.e.
the application thread that called the API will wait until all
compilations are finished.

java.lang.Compiler.compileClasses(String s) - the JIT will compile all
methods from classes that match the given string.

java.lang.Compiler.disable() - disables all future JIT compilations.

java.lang.Compiler.enable() - resumes JIT compilations.

IMO dropping these APIs would not be a great loss.

> What JEP 165 is proposing can only statically configure JIT behaviors for
> HotSpot. The same approach doesn't seem to cover what J9 used to support.
> 
> Could you please share more background on the discussions that led to the
> decision?

As you would expect, IBM and Oracle talk regularly about all things
Java, and this topic was raised as a heads-up that it was coming to
OpenJDK.  So there really isn't any background to the discussion.

Regards,
Tim
(IBM Java team)

> On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks 
> wrote:
> 
>> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler
>>
>> :-)
>>
>>
>> On 9/7/16 2:44 PM, Remi Forax wrote:
>>
>>> Yes, i like this patch :)
>>>
>>> Aleksey, It's worst than what you think because for a lot of people
>>> Compiler == java compiler and not JIT compiler so they try to compile a
>>> .java file with the method compileClasses(String).
>>>
>>> I'm glad this class will disappear soon.
>>>
>>> Rémi
>>>
>>> - Mail original -
>>>
>>>> De: "Aleksey Shipilev" 
>>>> À: "Stuart Marks" , "core-libs-dev" <
>>>> core-libs-dev@openjdk.java.net>
>>>> Envoyé: Mercredi 7 Septembre 2016 23:34:02
>>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler
>>>>
>>>
>>> On 09/07/2016 11:52 PM, Stuart Marks wrote:
>>>>
>>>>> Please review this small patch to deprecate java.lang.Compiler for
>>>>> removal.
>>>>>
>>>>
>>>> Yes, +1.
>>>> This class is very confusing to have these days.
>>>>
>>>> -Aleksey
>>>>
>>>

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

[Alan Bateman]

On 07/09/2016 21:52, Stuart Marks wrote:


Hi all,

Please review this small patch to deprecate java.lang.Compiler for 
removal.

Looks good, often confusing to see it in the javadoc.

-Alan

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

[Krystal Mok]

Hi Stuart,

Thanks for your reply. Indeed, the class doesn't really fit into the modern
world as it is now, for its original intended purpose. So, for its original
intent of configuring and controlling the JIT compiler(s), I'm more than
happy about the deprecation.

There are a couple of scenarios that I know of that make uses of the
java.lang.Compiler class as a generic entry point into the VM, not related
to the original intent at all. Let me think a bit about how to phrase those
scenarios correctly and update in a follow-up reply.

Thanks,
Kris

On Wed, Sep 7, 2016 at 4:42 PM, Stuart Marks 
wrote:

> Hi Kris,
>
> Well, there's not much background. We did contact IBM in regard to the
> mentions of java.lang.Compiler from their product pages, and they were OK
> with deprecating the API for removal. I can't speak to what impact this
> might have on IBM's products.
>
> I don't know much about JEP 165 [1] but it does appear to be able to
> update compiler directives at runtime. It doesn't seem to match the
> semantics of java.lang.Compiler. On the other hand, j.l.Compiler was
> introduced in the JDK 1.0 time frame, before production Java JIT compilers
> were delivered, so it's unlikely that its semantics match the needs of a
> modern JIT implementation.
>
> I really don't think anything is being lost by the deprecation and
> eventual removal of java.lang.Compiler. If anything, it's an improvement,
> as Rémi noted, since people will no longer confuse it with an API for
> invoking javac.
>
> s'marks
>
> [1] http://openjdk.java.net/jeps/165
>
> On 9/7/16 3:45 PM, Krystal Mok wrote:
>
> Hi Stuart,
>
> I see that on the JBS page, your most recent comment says it's been
> decided that for JDK9 it's okay to deprecate and forRemoval=true, while
> also mentioning the uses of this class in IBM's implementation.
>
> Does that mean IBM has agreed on the deprecation of this class? I thought
> J9 had features that allowed Java applications to do fine-grained control
> over the JIT compiler at runtime, e.g. force compilation of specified
> methods *at some certain point* in the program.
> What JEP 165 is proposing can only statically configure JIT behaviors for
> HotSpot. The same approach doesn't seem to cover what J9 used to support.
>
> Could you please share more background on the discussions that led to the
> decision?
>
> Thanks,
> Kris
>
> On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks 
> wrote:
>
>> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler
>>
>> :-)
>>
>>
>> On 9/7/16 2:44 PM, Remi Forax wrote:
>>
>>> Yes, i like this patch :)
>>>
>>> Aleksey, It's worst than what you think because for a lot of people
>>> Compiler == java compiler and not JIT compiler so they try to compile a
>>> .java file with the method compileClasses(String).
>>>
>>> I'm glad this class will disappear soon.
>>>
>>> Rémi
>>>
>>> - Mail original -
>>>
>>>> De: "Aleksey Shipilev" 
>>>> À: "Stuart Marks" , "core-libs-dev" <
>>>> core-libs-dev@openjdk.java.net>
>>>> Envoyé: Mercredi 7 Septembre 2016 23:34:02
>>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler
>>>>
>>>
>>> On 09/07/2016 11:52 PM, Stuart Marks wrote:
>>>>
>>>>> Please review this small patch to deprecate java.lang.Compiler for
>>>>> removal.
>>>>>
>>>>
>>>> Yes, +1.
>>>> This class is very confusing to have these days.
>>>>
>>>> -Aleksey
>>>>
>>>
>
>

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

[Stuart Marks]

Hi Kris,

Well, there's not much background. We did contact IBM in regard to the mentions 
of java.lang.Compiler from their product pages, and they were OK with 
deprecating the API for removal. I can't speak to what impact this might have on 
IBM's products.


I don't know much about JEP 165 [1] but it does appear to be able to update 
compiler directives at runtime. It doesn't seem to match the semantics of 
java.lang.Compiler. On the other hand, j.l.Compiler was introduced in the JDK 
1.0 time frame, before production Java JIT compilers were delivered, so it's 
unlikely that its semantics match the needs of a modern JIT implementation.


I really don't think anything is being lost by the deprecation and eventual 
removal of java.lang.Compiler. If anything, it's an improvement, as Rémi noted, 
since people will no longer confuse it with an API for invoking javac.


s'marks

[1] http://openjdk.java.net/jeps/165


On 9/7/16 3:45 PM, Krystal Mok wrote:

Hi Stuart,

I see that on the JBS page, your most recent comment says it's been decided 
that for JDK9 it's okay to deprecate and forRemoval=true, while also 
mentioning the uses of this class in IBM's implementation.


Does that mean IBM has agreed on the deprecation of this class? I thought J9 
had features that allowed Java applications to do fine-grained control over 
the JIT compiler at runtime, e.g. force compilation of specified methods /at 
some certain point/ in the program.
What JEP 165 is proposing can only statically configure JIT behaviors for 
HotSpot. The same approach doesn't seem to cover what J9 used to support.


Could you please share more background on the discussions that led to the 
decision?


Thanks,
Kris

On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks <mailto:stuart.ma...@oracle.com>> wrote:


Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler

:-)


On 9/7/16 2:44 PM, Remi Forax wrote:

Yes, i like this patch :)

Aleksey, It's worst than what you think because for a lot of people
Compiler == java compiler and not JIT compiler so they try to compile
a .java file with the method compileClasses(String).

I'm glad this class will disappear soon.

Rémi

- Mail original -

De: "Aleksey Shipilev" mailto:aship...@redhat.com>>
À: "Stuart Marks" mailto:stuart.ma...@oracle.com>>, "core-libs-dev"
        mailto:core-libs-dev@openjdk.java.net>>
Envoyé: Mercredi 7 Septembre 2016 23:34:02
Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler


On 09/07/2016 11:52 PM, Stuart Marks wrote:

Please review this small patch to deprecate java.lang.Compiler
for removal.


Yes, +1.
This class is very confusing to have these days.

-Aleksey

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

[Krystal Mok]

Hi Stuart,

I see that on the JBS page, your most recent comment says it's been decided
that for JDK9 it's okay to deprecate and forRemoval=true, while also
mentioning the uses of this class in IBM's implementation.

Does that mean IBM has agreed on the deprecation of this class? I thought
J9 had features that allowed Java applications to do fine-grained control
over the JIT compiler at runtime, e.g. force compilation of specified
methods *at some certain point* in the program.
What JEP 165 is proposing can only statically configure JIT behaviors for
HotSpot. The same approach doesn't seem to cover what J9 used to support.

Could you please share more background on the discussions that led to the
decision?

Thanks,
Kris

On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks 
wrote:

> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler
>
> :-)
>
>
> On 9/7/16 2:44 PM, Remi Forax wrote:
>
>> Yes, i like this patch :)
>>
>> Aleksey, It's worst than what you think because for a lot of people
>> Compiler == java compiler and not JIT compiler so they try to compile a
>> .java file with the method compileClasses(String).
>>
>> I'm glad this class will disappear soon.
>>
>> Rémi
>>
>> - Mail original -
>>
>>> De: "Aleksey Shipilev" 
>>> À: "Stuart Marks" , "core-libs-dev" <
>>> core-libs-dev@openjdk.java.net>
>>> Envoyé: Mercredi 7 Septembre 2016 23:34:02
>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler
>>>
>>
>> On 09/07/2016 11:52 PM, Stuart Marks wrote:
>>>
>>>> Please review this small patch to deprecate java.lang.Compiler for
>>>> removal.
>>>>
>>>
>>> Yes, +1.
>>> This class is very confusing to have these days.
>>>
>>> -Aleksey
>>>
>>

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

[Stuart Marks]

Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler

:-)

On 9/7/16 2:44 PM, Remi Forax wrote:

Yes, i like this patch :)

Aleksey, It's worst than what you think because for a lot of people Compiler == 
java compiler and not JIT compiler so they try to compile a .java file with the 
method compileClasses(String).

I'm glad this class will disappear soon.

Rémi

- Mail original -

De: "Aleksey Shipilev" 
À: "Stuart Marks" , "core-libs-dev" 

Envoyé: Mercredi 7 Septembre 2016 23:34:02
Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler



On 09/07/2016 11:52 PM, Stuart Marks wrote:

Please review this small patch to deprecate java.lang.Compiler for removal.


Yes, +1.
This class is very confusing to have these days.

-Aleksey

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

[Remi Forax]

Yes, i like this patch :)

Aleksey, It's worst than what you think because for a lot of people Compiler == 
java compiler and not JIT compiler so they try to compile a .java file with the 
method compileClasses(String).

I'm glad this class will disappear soon.

Rémi

- Mail original -
> De: "Aleksey Shipilev" 
> À: "Stuart Marks" , "core-libs-dev" 
> 
> Envoyé: Mercredi 7 Septembre 2016 23:34:02
> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler

> On 09/07/2016 11:52 PM, Stuart Marks wrote:
>> Please review this small patch to deprecate java.lang.Compiler for removal.
> 
> Yes, +1.
> This class is very confusing to have these days.
> 
> -Aleksey

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

[Mandy Chung]

Looks fine to me.

Mandy

> On Sep 7, 2016, at 1:52 PM, Stuart Marks  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.
>  *
> - *  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.
> - *
> - *  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
>  */
> +@Deprecated(since="9", forRemoval=true)
> public final class Compiler  {
> private Compiler() {}   // don't make instances
> 

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

[Aleksey Shipilev]

On 09/07/2016 11:52 PM, Stuart Marks wrote:
> Please review this small patch to deprecate java.lang.Compiler for removal.

Yes, +1.
This class is very confusing to have these days.

-Aleksey

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

[Stuart Marks]

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.
  *
- *  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.
- *
- *  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
  */
+@Deprecated(since="9", forRemoval=true)
 public final class Compiler  {
 private Compiler() {}   // don't make instances