Hi Martin,
What version of TLR are you looking at? As far as I remmember, the
InetAddress-related code to obtain initial seed has been replaced by
NetworkInterface.getHardwareAddress(). Is this still triggering the
initialization of InetAddress or is this the case of using
On 06/19/2014 08:32 AM, Stanimir Simeonoff wrote:
I wonder why just don't use the /dev/random if available on *nix -
implemented by sun.security.provider.NativePRNG or
sun.security.mscapi.PRNG() on Windows that calls CryptGenRandom.
Both support SecureRandomSpi.engineGenerateSeed(int) that
On 19/06/2014 05:25, Martin Buchholz wrote:
ThreadLocalRandom's clinit method creates an intermediate broken state of
ThreadLocalRandom and then proceeds to run some networking code to get some
more machine-specific entropy in initialSeed(). This will fail if the
networking code ever
Hi,
I noticed an inconsistency in calling TLR.localInit() method. Everywhere
it's called conditionaly if thread-local probe is zero except in
TLR.nextSecondarySeed() where it's called if secondary seed is zero.
This re-initializes the probe and seed even though they might have
already been
Or, even better, why not just using the next value from the seeder
sequence for the initial value of secondary seed and avoid interaction
with TLR's main seed/probe:
diff -r 5b45a5efe417
src/share/classes/java/util/concurrent/ThreadLocalRandom.java
---
On 06/19/2014 04:48 AM, Peter Levart wrote:
Or, even better, why not just using the next value from the seeder sequence
for the initial value of secondary seed and avoid interaction with TLR's main
seed/probe:
Thanks! Or better, just use mix32:
+if ((r =
I've just take a look to bug 8047341 [1] and I think it's a javac bug
and not a bug in the lambda meta-factory,
moreover, Eclipse generates a code which doesn't throw an exception at
runtime.
In list.stream().forEach(TestString::new), TestString::new reference the
constructor of TestString
On 19/06/14 13:53, Remi Forax wrote:
as you can see, javac generate an invokedynamic call with a Foo
instead of a FooBase which I think is the correct behavior.
You mean the other way around?
Maurizio
On 06/19/2014 03:00 PM, Maurizio Cimadamore wrote:
On 19/06/14 13:53, Remi Forax wrote:
as you can see, javac generate an invokedynamic call with a Foo
instead of a FooBase which I think is the correct behavior.
You mean the other way around?
oops,
s/the correct/not the correct
Please review the following simple changeset to identify the offending JAR file
following a signature verification error.
Previously, only the offending entry in the JAR was identified.
This helps during troubleshooting when several JAR files being processed.
The request was originally
Hi,
an updated webrev with reworked, public methods is available here:
http://cr.openjdk.java.net/~redestad/8041972/webrev.8/
Reviews are yet again appreciated!
/Claes
On 06/17/2014 05:43 PM, Claes Redestad wrote:
Ok, I'm working on improving code and comments based on feedback. I'll
split
On Thu, Jun 19, 2014 at 1:22 AM, Alan Bateman alan.bate...@oracle.com
wrote:
On 19/06/2014 05:25, Martin Buchholz wrote:
ThreadLocalRandom's clinit method creates an intermediate broken state of
ThreadLocalRandom and then proceeds to run some networking code to get
some
more
Hi Sherman,
Looks ok.
Thanks, Roger
On 6/16/2014 1:00 PM, Xueming Shen wrote:
OK, let's go the non-controversial approach. The webrev has been
updated to simply remove
those redundant/duplicated class files from the builder and use the
updated version of the tzdb
builder.
I shortened the output to display only the JAR filename to avoid leaking
filesystem information.
I’ve updated the webrev in-place.
Thanks.
On 19 Jun 2014, at 17:59, Vincent Ryan vincent.x.r...@oracle.com wrote:
Please review the following simple changeset to identify the offending JAR
Hello,
I'd prefer to see the CheckJarSigError.sh as a Java program.
Cheers,
-Joe
On 06/19/2014 02:21 PM, Vincent Ryan wrote:
I shortened the output to display only the JAR filename to avoid leaking
filesystem information.
I’ve updated the webrev in-place.
Thanks.
On 19 Jun 2014, at
Launcher support for modified Native Memory Tracking mechanism in JVM in
JDK9.
Webrev : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
bug : https://bugs.openjdk.java.net/browse/JDK-8042469
CCC : http://ccc.us.oracle.com/8042469
Thanks.
-neil
Hi Neil,
1054 envName = malloc(pbuflen);
envName is never freed looks like. Probably not a big deal since this runs
only if launcher is traced, but thought I'd mention it.
Sent from my phone
On Jun 19, 2014 8:30 PM, Neil Toda neil.t...@oracle.com wrote:
Launcher support
Thanks Vitaly. Best to cleanup. I'll make that change.
-neil
On 6/19/2014 5:39 PM, Vitaly Davidovich wrote:
Hi Neil,
1054 envName = malloc(pbuflen);
envName is never freed looks like. Probably not a big deal since this
runs only if launcher is traced, but thought
18 matches
Mail list logo
