Accepted.
Please review http://ccc.us.oracle.com/8169312. In fact, can we
deprecate the getSeed() method? It's not unsafe so we don't need to give
it a forRemoval value.
Thanks
Max
On 11/4/2016 10:54 PM, Sean Mullan wrote:
* 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.w...@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
