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@oracle.com> command(Object
<cid:part1.05E042AF.0D7D0BF0@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.ma...@oracle.com
<mailto: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/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
*/
+@Deprecated(since="9", forRemoval=true)
public final class Compiler {
private Compiler() {} // don't make instances
