On Sun, 19 Mar 2023 14:38:55 GMT, Alan Bateman <al...@openjdk.org> wrote:
> For reference, here's the discussion from 2016 when it was proposed to
> deprecate j.l.Compiler, for removal. Tim Ellison from IBM engaged in that
> discussion as one of the replies asked about applications running on the J9
> VM using this API.
So it seems in 2016 IBM in was ok with an eventual removal of this class
("these APIs can be removed without grief")
However, I see that later in the thread Azul Systems raised concerns about a
removal:
https://mail.openjdk.org/pipermail/core-libs-dev/2016-September/043585.html
https://mail.openjdk.org/pipermail/core-libs-dev/2016-September/043646.html
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.
Would be good if someone from Azul Systems could give a 2023 assessment on
removing this class?
> The discussion is also a reminder that -Djava.compiler=NONE is the equivalent
> of -Xint, I thought that system property was dropped a long time ago.
It exists in System.getProperties Javadocs at least:
* <tr><th scope="row">{@systemProperty java.compiler}</th>
* <td>Name of JIT compiler to use</td></tr>
Was this just for reference or are you suggesting that this PR is blocked by
the 'java.compiler' somehow?
-------------
PR: https://git.openjdk.org/jdk/pull/13092
