RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator

[Valerie Peng]

Thanks for the feedback.

I have updated webrev to address your comments: 
http://cr.openjdk.java.net/~valeriep/8182484/webrev.01/
CSR has also been updated and proposed.
Valerie

On 11/14/2017 10:47 AM, Sean Mullan wrote:
> On 11/8/17 6:47 PM, Valerie Peng wrote:
>> Hi, Sean,
>>
>> I updated the webrev in place - now this change contains only javadoc 
>> update of DSAKeyPairGenerator interface.
>> CSR has also been updated accordingly. Could you please take a look?
>
> Sure.
>
>   35  * DSAKeyPairGenerator, each provider must supply (and document) a
>   36  * default initialization.
>
> I suggest saying "should" instead of "must" since we can't really 
> require this to be documented, esp. for a 3rd-party provider. Also I 
> would say "each provider that implements this interface ...".
>
>   52  * DSAKeyPairGenerator, then call one of the {@code initialize} 
> methods
>
> Slight rewording suggestion: "DSAKeyPairGenerator and calling one of 
> the {@code initialize} methods"
>
>  103      * thrown. It is guaranteed that there will always be
>  104      * default parameters for modulus lengths of 512, 1024, and 
> 2048 bits.
>
> I guess "guaranteed" is referring to any impl of DSAKeyPairGenerator, 
> but it is kind of hard to enforce that if you are using a 3rd-party 
> provider. I think we should consider just removing this sentence 
> entirely and leaving the requirements up to the implementation. It's 
> also unusual that we would require 512-bits, and hard-coding that 
> might make it hard to remove later on. Minimally, I think we should 
> remove 512.
>
> --Sean
>
>>
>> Thanks,
>> Valerie
>>
>> On 11/2/2017 6:24 PM, Valerie Peng wrote:
>>> Sean,
>>>
>>> Could you help review this RFE below? It's mainly the javadoc update 
>>> of java.security.interfaces.DSAKeyPairGenerator which replaces the 
>>> 1024-bit default value with provider-specific one and removal of the 
>>> earlier changes for working around this javadoc limitation. I reused 
>>> the wordings from existing security classes.
>>>
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8182484
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8182484/webrev.00/
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8190569
>>>
>>> Thanks,
>>> Valerie
>>