On 07/03/2014 07:59 PM, Martin Buchholz wrote:
On Wed, Jul 2, 2014 at 7:39 AM, Claes Redestad
mailto:claes.redes...@oracle.com>> wrote:
Hi Peter,
perhaps the synchronized(this)-block in
NameServiceAddresses::get() can be replaced with a ReentrantLock?
Applying this on top
On 03/07/2014 11:12, Peter Levart wrote:
I have filed a RFE that is more suitable for this change:
https://bugs.openjdk.java.net/browse/JDK-8049228
So, is it strictly necessary to fix JDK-7186258 alone before applying
the change for JDK-8049228 although it would supersede it?
We can close
On 03/07/2014 09:43, Peter Levart wrote:
Hi,
I noticed a data race in java.net.URL:
https://bugs.openjdk.java.net/browse/JDK-8049220
I propose the following simple patch:
http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.01/
A good catch and the change looks good to me. I
Hi,
We know that URL.equals and hashCode are fundamentally broken. But
URL.equals is even more broken than hashCode. Nevertheless, URL.equals
is used explicitly in the following places in JDK:
java.security.CodeSource.matchLocation
java.security.CodeSource.equals
java.util.jar.JarVerifier.Ver
On 07/01/2014 10:04 PM, Martin Buchholz wrote:
I haven't looked at the patch, but generally ... all uses of
currentTimeMillis to measure elapsed time should be migrated to use
difference of two nanoTime values, and such a change should be done
independently of other changes.
I have filed a RFE
Hi,
I noticed a data race in java.net.URL:
https://bugs.openjdk.java.net/browse/JDK-8049220
I propose the following simple patch:
http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.01/
Regards, Peter
