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