The options were already deprecated long ago:
$ $J14/bin/jarsigner
Usage: jarsigner [options] jar-file alias
jarsigner -verify [options] jar-file [alias...]
...
[-altsigner <class>] class name of an alternative signing mechanism
(This option has been deprecated.)
[-altsignerpath <pathlist>] location of an alternative signing mechanism
(This option has been deprecated.)
...
and they are listed in a "Deprecated Options" section in the tooldoc with
"might be removed in a future JDK release".
The only problem is I forgot to add a forRemoval=true argument to the
@Deprecated annotation of the classes.
--Max
> On Apr 11, 2020, at 10:20 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
>
> 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.
