On Sep 5, 2013, at 7:50 AM, Paul Sandoz wrote:
>> The change to pass in the random number generator appears fine.
>> There's probably no need for a strong random number generator in this
>> case, though.
> If that is the case why not just leave the method as is and replace
> SecureRandom with Thr
On Sep 5, 2013, at 7:02 AM, Alan Eliasen wrote:
> On 09/04/2013 05:26 PM, Brian Burkhalter wrote:
>> I have updated the webrev
>>
>> http://cr.openjdk.java.net/~bpb/7189139/
>>
>> to add the two-parameter version of isProbablePrime() which was
>> discussed. Naturally a CCC request would be nee
On 09/04/2013 05:26 PM, Brian Burkhalter wrote:
> I have updated the webrev
>
> http://cr.openjdk.java.net/~bpb/7189139/
>
> to add the two-parameter version of isProbablePrime() which was
> discussed. Naturally a CCC request would be needed in the event this
> were to go forward.
The change
Hello,
I don't think the specification of the new method is acceptable in its
current form. At a minimum, some guidance should be provided on the
properties the supplied random number generator should have to work with
the primality tests that are being used. (Offhand, I don't know what
those
On Sep 3, 2013, at 5:11 PM, Brian Burkhalter wrote:
> On Sep 3, 2013, at 5:09 PM, Doug Lea wrote:
>
>> Only adding isProbablePrime seems to be an OK conservative
>> move: no existing usages would be affected, but users would
>> need to somehow be told that they could improve performance
>> by cha
On Sep 3, 2013, at 5:09 PM, Doug Lea wrote:
> Only adding isProbablePrime seems to be an OK conservative
> move: no existing usages would be affected, but users would
> need to somehow be told that they could improve performance
> by changing their code to use the new method with
> ThreadLocalRan
On 09/03/2013 07:52 PM, Brian Burkhalter wrote:
On Sep 3, 2013, at 4:46 PM, Doug Lea wrote:
I assume you mean to change line 898:
if (rnd == null) {
rnd = ThreadLocalRandom.current();; // was: getSecureRandom();
}
Yes.
This seems fine in terms of sufficient RNG qua
On Sep 3, 2013, at 4:46 PM, Doug Lea wrote:
> I assume you mean to change line 898:
>
>if (rnd == null) {
>rnd = ThreadLocalRandom.current();; // was: getSecureRandom();
>}
Yes.
> This seems fine in terms of sufficient RNG quality and better
> performance. Also in te
On 09/03/2013 03:06 PM, Brian Burkhalter wrote:
So it looks like there are two decisions to be made on this topic:
On Sep 3, 2013, at 1:21 AM, Paul Sandoz wrote:
add the following method to BigInteger
public boolean isProbablePrime(int certainty, Random end) ,
which allows primality testing wi
So it looks like there are two decisions to be made on this topic:
On Sep 3, 2013, at 1:21 AM, Paul Sandoz wrote:
>>> add the following method to BigInteger
>>> public boolean isProbablePrime(int certainty, Random end) ,
>>> which allows primality testing with arbitrary Random objects.
>>> In man
On Sep 3, 2013, at 7:14 AM, Bradford Wetmore
wrote:
> Bill also wrote in that email:
>
> > add the following method to BigInteger
> > public boolean isProbablePrime(int certainty, Random end) ,
> > which allows primality testing with arbitrary Random objects.
> > In many cases, using a well seed
Sorry, I haven't been following the Random discussions until now, I
haven't been subscribed to core-lib-dev in a while.
I was specifically asked to comment on Brian's proposed change.
Paul pointed out something Bill Pugh wrote:
> Right, see here:
>
>
http://mail.openjdk.java.net/pipermail/cor
On Aug 26, 2013, at 3:15 PM, Paul Sandoz wrote:
>> As discussed in the relevant threads in the original bug report, the
>> actual fix should be a very accurate replacement of SR with some other
>> faster and reliable RNG to avoid the inherent scalability bottlenecks.
>>
>
> I don't know about th
On Aug 26, 2013, at 2:19 PM, Aleksey Shipilev
wrote:
> Hi Brian,
>
> On 08/24/2013 03:39 AM, Brian Burkhalter wrote:
>> file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html
>>
>> would be appreciated.
>
> I'm puzzled over this fix.
>
> Isn't the scalability bottleneck being inhere
Hi Brian,
On 08/24/2013 03:39 AM, Brian Burkhalter wrote:
> file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html
>
> would be appreciated.
I'm puzzled over this fix.
Isn't the scalability bottleneck being inherent to SecureRandom, because
it piggybacks on the system entropy pool, whic
On Aug 23 2013, at 17:10 , Brian Burkhalter wrote:
>
> On Aug 23, 2013, at 5:06 PM, Mike Duigou wrote:
>
>> I would strongly recommend holding back on this change until someone
>> familiar with the crypto implications takes a look at it. Unfortunately
>> neither the random constructor nor pro
On Aug 23, 2013, at 5:06 PM, Mike Duigou wrote:
> I would strongly recommend holding back on this change until someone familiar
> with the crypto implications takes a look at it. Unfortunately neither the
> random constructor nor probablePrime indicate any expectations regarding the
> quality
I would strongly recommend holding back on this change until someone familiar
with the crypto implications takes a look at it. Unfortunately neither the
random constructor nor probablePrime indicate any expectations regarding the
quality of random numbers needed from the offered PRNG.
- Changin
On Aug 23, 2013, at 4:39 PM, Brian Burkhalter wrote:
> With respect to this issue
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7189139
>
> any comments on this potential fix
>
> file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html
Correction to this webrev link:
http://cr
With respect to this issue
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7189139
any comments on this potential fix
file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html
would be appreciated.
Rudimentary testing with JMH (http://openjdk.java.net/projects/code-tools/jmh/)
did not
20 matches
Mail list logo
