RFR 8242260: Remove customizable ContentSigner from jarsigner

[Alan Bateman]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200411/10f01449/attachment.htm>