On 09/01/2015 02:50 AM, Weijun Wang wrote:
Updated a little: rewrite of jarsigner tool itself using the JarSigner
API included. Still at the same URL below.
I notice that you don't use the new JarSigner API at all in the
jarsigner tool and go straight to the BuilderX/JarSignerX classes. This
worries me as it means the API is not sufficient for our own uses and
therefore may not be sufficient for anyone else either.
I think the flaw is that we have not made it extensible. JarSigner is a
final class, so it can't be subclassed with new functionality. Removing
the final keyword would be easy, but that doesn't really solve the problem.
It looks like we are not the first ones to tackle this problem. Here is
one link:
https://weblogs.java.net/blog/emcmanus/archive/2010/10/25/using-builder-pattern-subclasses
Can you think about this some more and see if the design can be adapted
to allow JarSigner to be extended?
Thanks,
Sean
--Max
On 08/24/2015 09:56 PM, Weijun Wang wrote:
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8056174/webrev.02/
A new JarSigner public API is introduced to OpenJDK. The code change
chooses a two-layer implementation style, with public JarSigner/Builder
in jdk.security and private JarSignerX/BuilderX in sun.security. The
private side contains some unpopular options which I hope can be used to
implement the jarsigner tool itself in another changeset.
Some spec clarification is made since my last mail [1], including
Builder#sign, JarSigner#getDigestAlg, and JarSigner#getSigAlg. In
Builder, I am still using short method names (sigAlg, digestAlg, and
tsa) since I think the jarsigner option names are already widely
accepted. Otherwise, a name like setDigestAlgorithm seems a little
unfamiliar.
Thanks
Max
[1]
http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012636.html
