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
