On 11/04/2020 14:20, Sean Mullan wrote:
On 4/11/20 6:31 AM, Weijun Wang wrote:
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.
Here is what JEP 277 [1] says:
The following elements are to be added to the java.lang.Deprecated
annotation type:
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.
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.
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.
-Alan.
