<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 11/04/2020 14:20, Sean Mullan wrote:<br>
<blockquote type="cite"
cite="mid:03367944-cac1-11be-dee3-883294bc7131@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 4/11/20 6:31 AM, Weijun Wang
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6333B5C5-1426-4A92-AD83-7E9F4147EFEA@oracle.com">
<pre class="moz-quote-pre" wrap="">If the rule is that an API must be labeled forRemoval=true before it's really removed, then I cannot remove them in JDK 15.</pre>
</blockquote>
<p>Here is what JEP 277 [1] says:<br>
</p>
<blockquote>
<pre>The following elements are to be added to the java.lang.Deprecated annotation type:</pre>
</blockquote>
<blockquote>
<pre>A method forRemoval() returning a boolean. If true, it means that this
API element is earmarked for removal in a future release. If false, the
API element is deprecated, but there is currently no intention to remove
it in a future release. The default value of this element is false.</pre>
</blockquote>
<p>Since these are JDK and not standard SE APIs, maybe we don't
have to abide by that, but I think as a best practice we
probably should. You could check with Joe Darcy and Stuart Marks
if you want to be more sure.<br>
</p>
</blockquote>
There is a JDK-specific API and command line options on the table
here. Removing these without notice may surprise some. For the APIs
then you could terminally deprecate them in JDK 15 and remove them
in a future release. I don't think JEP 277 has been updated to
provide guidance in the context of the new release cadence so use
your best judgement (JDK 16 might be too soon to remove). As regards
the CLI options then you could add a warning to jarsigner so that
anyone using this tool with existing content signers (compiled for
JDK 8 for example) has some chance of seeing that the options will
be going away in the future.<br>
<br>
-Alan.<br>
</body>
</html>