On 01/13/2016 07:44 AM, Wang Weijun wrote:
Hi David
On Jan 13, 2016, at 8:08 PM, David M. Lloyd <[email protected]> wrote:
On 01/12/2016 07:02 PM, Wang Weijun wrote:
A new webrev at
http://cr.openjdk.java.net/~weijun/8058778/webrev.09/
A couple of questions/comments...
+ public interface Builder
+ <S extends Certificate,T extends Builder<S,T>> {
What is the point of the "T" self-type variable? It does not seem to be
referenced. Also the type parameters are not documented in the interface JavaDoc, or
generally anywhere.
If there were a mutator defined here, it could be written as "T setSomething()"
so that when called in a child interface it can return the child type instead the base
type. Will add some document.
That said, I haven't applied this trick in X509Certificate.Builder, what if
there is a 2nd-level child interface? I'll do some experiments.
In my experience, self-type parameters usually end up with trouble.
It's easier/safer to just override mutators in sub-interfaces to return
the more specific type.
Also in places like this....
[...]
...it's using UOE for unsupported format, which doesn't seem right.
It should be IllegalArgumentException, or a sub-type (although I cannot find
one).
Also, it seems like you could check "type" up at the top.
I can use Class#isAssignable.
The docs don't seem to specify whether the CSR block is consumed in the event
of an invalid type Class being passed in.
I just copied the existing spec for generateCertificate(), in fact in some
places I haven't done s/certificate/certificate request/ yet!
The current behavior is that it will consume one ----BEGIN...END---- block
(with optional text before the block) or one DER SEQUENCE, or undefined if no
such data structure are found. However, I am not sure if I need to document
that as a requirement. Do you want any guarantee?
I think it's probably a good idea to at least document what happens in
the event of various errors.
It would be nice if this could be turned into some kind of generalized
PEM support some day...
--
- DML
