Thanks everyone for the input. Even though many people who are way
smarter than me already tried to beat the naive implementation, I'll
try too, just for the fun of it. I'll post my updates here if I find
something worthy of mentioning.
Zoltan
On Fri, Apr 4, 2014 at 7:13 PM, Martin Buchholz
Since the testlibrary exists even in the JDK part I would like to add the
Serviceability and Corelibs teams to this discussion.
Thanks,
Katja
- Original Message -
From: david.hol...@oracle.com
To: hotspot-...@openjdk.java.net
Sent: Monday, April 7, 2014 3:50:14 AM GMT +01:00 Amsterdam
Hi,
https://github.com/cowtowncoder/java-uuid-generator
JDK's java.util.UUID has flawed implementation of compareTo(), which uses
naive comparison of 64-bit values.
Anyone familiar with the JDK UUID implementation care to comment?
Paul.
Hi,
I'd like to ask for approval and sponsoring fix for following issue (escalation
from customer):
JBS: https://bugs.openjdk.java.net/browse/JDK-8033113
BugDB: https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=17348912
jaxws changeset:
This looks good to me Miran. I can sponsor it for you.
-Chris.
On 7 Apr 2014, at 17:22, Miroslav Kos miroslav@oracle.com wrote:
Hi,
I'd like to ask for approval and sponsoring fix for following issue
(escalation from customer):
JBS: https://bugs.openjdk.java.net/browse/JDK-8033113
On 04/04/2014 10:08 AM, Xueming Shen wrote:
On 4/3/14 4:43 PM, Jeremy Manson wrote:
Good catch, thanks.
I think we should probably just go with the (equivalent to the) StringBuffer
variant. I'm pretty loathe to modify the StringBuilder directly if we are
going to back that change out.
Do
The issue is that the comparison is done upon the signed most significant and
least significant long values.
At minimum UUIDs should be compared as if they were 128-bit unsigned values.
Beyond that, version (which is a type not a version) 1 and 2 UUIDs (time
based and DCE), should have a more
Hi Martin,
Can you suggest some example libraries or programs that we should be
testing against?
Thanks, Roger
On 3/26/2014 1:54 PM, Martin Buchholz wrote:
Peter and Roger, please stop going down this road until you have a
solution for my show-stopper problem, that in the below you are
Thanks, Chris.
I have to do one more iteration:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.05/
I have to revert changes related to BMH::reinvokerTarget.
Removal of reinvokerTarget in generated concrete BMH classes introduces
serious performance regression, since BMH::reinvokerTarget
