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.
--Max
> On Apr 11, 2020, at 5:44 PM, Peter Levart <peter.lev...@gmail.com> wrote:
>
>
>
> On 4/10/20 11:45 AM, Weijun Wang wrote:
>> Hi Peter,
>>
>> This is awkward but I've seen method that is marked deprecated for removal
>> which simply throws an UnsupportedOperationException.
>>
>> Suppose someone has an "enhanced" jarsigner that is also calling the
>> JarSigner API. It might also support customized ContentSigner but is also
>> used by no one. If the classes were removed the tool will not compile. If
>> the classes remain but JarSigner no longer uses it, it will simply throws an
>> UOE which is harmless to most people.
>>
>> Maybe the tool maintainer has already added
>> "@SuppressWarnings("deprecated")", but this time they will see a new warning
>> on "[removal]", and they will know they need to remove it within a year.
>>
>> --Max
>
> Hi Max,
>
> What I was trying to say is that even if you remove ContentSigner class(es)
> from JDK 15, users will still be able to compile either the special
> "enhanced" jarsigner or the ContentSigner implementations if they use
> -release 14 option. They will just not be able to run the "enhanced"
> jarsigner with JDK 15. So removing a class from JDK 15 is not so bad as it
> was before the -release option was available. At least from the standpoint of
> compilation. So it makes a little difference if you remove the classes or not
> when you also remove the options to use/run the classes with jarsigner. What
> you choose is of course up to you. I see Sean is suggesting that you keep the
> options in the jarsigner for JDK 15.
>
> Regards, Peter
>
>>
>>> On Apr 10, 2020, at 5:22 PM, Peter Levart <peter.lev...@gmail.com> wrote:
>>>
>>> Which brings me to this...
>>>
>>> If it is a requirement to use -release option to compile ContentSigner
>>> implementation class in order for them to be usable (with some older
>>> release of jarsigner), then ContentSigner classes could as well be removed
>>> from the JDK 15 API because their signature will still be available to the
>>> javac with appropriate -release 14 or older option. So compilation would
>>> still succeed.
>>>
>>> Peter
>>>
>>> On 4/10/20 11:07 AM, Peter Levart wrote:
>>>> What's the use of allowing compiling some classes if those classes can't
>>>> be used anywhere? They would be unusable in the new release of jarsigner.
>>>> Ok, they could be used in some older jarsigner if the classes were
>>>> compiled with appropriate -release option. So the usecase for not removing
>>>> the classes would be in a project that builds an implementation of
>>>> ContentSigner and then publishes it to be used in a project that still
>>>> uses an old jarsigner. Such ContentSigner project could then be upgraded
>>>> to use the new JDK/javac with appropriate -release option for compiling
>>>> ContentSigner implementation classes.
>>>>
>>>> Peter
>>>>
>>>> On 4/10/20 3:58 AM, Wang Weijun wrote:
>>>>> So the classes will be useless but at least old program still compiles.
>>>>> I'll modify the CSR and see how Joe thinks of this.
>>>>>
>>>>> Thanks,
>>>>> Max
>>>>>
>>>>>> 在 2020年4月9日，22:58，Sean Mullan <sean.mul...@oracle.com> 写道：
>>>>>>
>>>>>> On 4/9/20 10:52 AM, Weijun Wang wrote:
>>>>>>> All info for signing are passed into a ContentSigner through a
>>>>>>> ContentSignerParameters object. In order to pass more info, I’ll need
>>>>>>> to create new interface methods for it.
>>>>>> But you can just use your solution in JarSigner in the webrev below
>>>>>> where you are calling PKCS7.generateSignedData instead of ContentSigner.
>>>>>> Just because the ContentSigner APIs are still there doesn't mean you
>>>>>> have to use it in jarsigner (unless I am missing something).
>>>>>>
>>>>>> --Sean
>>>>>>
>>>>>>> —Max
>>>>>>>>> 在 2020年4月9日，21:27，Sean Mullan <sean.mul...@oracle.com> 写道：
>>>>>>>> On 4/9/20 3:13 AM, Wang Weijun wrote:
>>>>>>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS and
>>>>>>>>> EdDSA. Sigh.
>>>>>>>> Why would you need to do that if they are deprecated?
>>>>>>>>
>>>>>>>> --Sean
>>>>>>>>
>>>>>>>>> --Max
>>>>>>>>>>> 在 2020年4月9日，01:58，Sean Mullan <sean.mul...@oracle.com> 写道：
>>>>>>>>>> We never actually deprecated the com.sun.jarsigner package with a
>>>>>>>>>> forRemoval=true flag, so while it may be very low-risk to remove
>>>>>>>>>> these APIs, I feel that we should not remove it w/o prior notice.
>>>>>>>>>>
>>>>>>>>>> I would suggest adding the forRemoval=true for this package/APIs
>>>>>>>>>> instead, and plan on removing it in JDK 16 or 17.
>>>>>>>>>>
>>>>>>>>>> I'm ok with removing the jarsigner options because the man page
>>>>>>>>>> already warned that they may be removed.
>>>>>>>>>>
>>>>>>>>>> --Sean
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>>>>>>>> I am thinking about removing the `jarsigner -altsigner
>>>>>>>>>>> -altsignerpath` options and underlying classes:
>>>>>>>>>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>>>>>>>> Please review everything at:
>>>>>>>>>>> Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>>>>>>> CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>>>>>>> webrev :
>>>>>>>>>>> http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>>>>>>>> The CSR "Problem" section has more info on why it's better to
>>>>>>>>>>> remove it now.
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Max
>
