RFR 7004967: SecureRandom should be more explicit about threading

[Sean Mullan]

* SecureRandom

  131  * If this attribute is not set or is "false", this class will instead
  132  * synchronize access to each of the methods of the {@code 
SecureRandomSpi}
  133  * implementation.

Not all of the methods are synchronized - engineGetParameters is not, 
for example. I think to avoid ambiguity, you should list the names of 
the methods that are synchronized.

810      * @throws IllegalArgumentException if {@code numBytes} is negative

Since this is a new @throws, you really need to file a new CCC (or 
withdraw and amend the current one with this @throws).

Please also file a docs bug with a description of the new attribute.

* SecureRandomSpi

lines 63-83, I think the wording could be improved/simplified, how about:

See {@link SecureRandom} for additional details on thread safety. By
default, a SecureRandomSpi implementation is considered to be not safe 
for use by multiple concurrent threads and SecureRandom will 
synchronize access to each of the applicable engine methods (see 
SecureRandom for the list of methods). However, if a SecureRandomSpi 
implementation is thread-safe, the <a 
href="{@docRoot}/../technotes/guides/security/StandardNames.html#Service">service 
provider attribute</a> "ThreadSafe" should be set to "true" during its 
registration, as follows:

   put("SecureRandom.AlgName ThreadSafe", "true");

   or

   putService(new Service(this, "SecureRandom", "AlgName", className,
              null, Map.of("ThreadSafe", "true")));

{@code SecureRandom} will then call the applicable engine methods
without any synchronization.

--Sean

On 11/2/16 3:27 AM, Wang Weijun wrote:
> Ping again.
>
> There is an updated version at http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only changes.
>
> Thanks
> Max
>
>> On Aug 25, 2016, at 10:00 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> Please review the enhancement at
>>
>>  http://cr.openjdk.java.net/~weijun/7004967/webrev.00/
>>
>> Basically, we want SecureRandom to be more efficient by removing all synchronized keywords from its public methods and let an implementation to take care of thread-safety (We already did some in JDK-8098581). On the other hand, we need to make sure that existing implementations that have not synchronized correctly to behave just as good as before.
>>
>> Therefore a new Service Attribute "ThreadSafe" is introduced. If you think your implementation is already thread-safe, set it to "true" and SecureRandom will be happy. Otherwise, don't set it and SecureRandom will continuously call your SecureRandomSpi engine methods in synchronized blocks.
>>
>> Thanks
>> Max
>