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 <https://bugs.openjdk.java.net/browse/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.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


Reply via email to