mentation due to the introduction of synchronization:
>
> - random-byte-only 143.487 ± 10.932 ns/op
> - higher-precision 149.651 ± 8.438 ns/op
> - counter-based 245.036 ± 2.943 ns/op
>
> The best balance here might be to employ a higher-precision implementation as
On Mon, 19 May 2025 18:08:18 GMT, Roger Riggs wrote:
>> kieran-farrell has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> update RFC
>
> src/java.base/share/classes/java/util/UUID.java line 195:
>
>&g
On Mon, 19 May 2025 18:17:09 GMT, Roger Riggs wrote:
> Can the sub-microsecond value just be truncated and avoid the expensive
> divide operation?'
method 3 of secion 6.2 of
https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters
states
> start with the portion of the tim
On Tue, 20 May 2025 13:35:32 GMT, kieran-farrell wrote:
>> src/java.base/share/classes/java/util/UUID.java line 219:
>>
>>> 217: randomBytes[8] |= (byte) 0x80;
>>> 218:
>>> 219: return new UUID(randomBytes);
>>
>> This could
New API to the String.java class - replaceAllMapped(String,
Function) that allows regex based replacement via a user
defined function allowing dynamic replacemnt based on the match. It delegates
to the already existing Pattern.matcher().replaceAll(Function).
-
Commit messages:
- w
mentation due to the introduction of synchronization:
>
> - random-byte-only 143.487 ± 10.932 ns/op
> - higher-precision 149.651 ± 8.438 ns/op
> - counter-based 245.036 ± 2.943 ns/op
>
> The best balance here might be to employ a higher-precision implementation as
With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/),
this PR aims to add a new static method UUID.timestampUUID() which constructs
and returns a UUID in support of the new time generated UUID version.
The specification requires embedding the current timestamp in milli
On Tue, 20 May 2025 16:59:10 GMT, kieran-farrell wrote:
> New API to the String.java class - replaceAllMapped(String,
> Function) that allows regex based replacement via a user
> defined function allowing dynamic replacemnt based on the match. It delegates
> to the alre
On Tue, 20 May 2025 19:37:31 GMT, Philippe Marschall wrote:
>> There's no (time-based) relationship between the currentTimeMillis() value
>> and the nanoTime value.
>> They are independent clocks and are read separately and are un-correlated.
>> They won't be usable as lsb of the millis value.
On Wed, 28 May 2025 20:57:15 GMT, Roger Riggs wrote:
>> The first 48 bits need to be from the unix epoch time stamp in ms only to
>> remain complaint. If I understand correctly, to be able to guarantee that
>> the nsBits are actually time orderable, System.nanoTime() would have to be
>> pinned
On Sun, 8 Jun 2025 16:15:40 GMT, Kieran Farrell wrote:
>> With the recent approval of UUIDv7
>> (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new
>> static method UUID.timestampUUID() which constructs and returns a UUID in
>> support of the new tim
mentation due to the introduction of synchronization:
>
> - random-byte-only 143.487 ± 10.932 ns/op
> - higher-precision 149.651 ± 8.438 ns/op
> - counter-based 245.036 ± 2.943 ns/op
>
> The best balance here might be to employ a higher-precision implementation as
mentation due to the introduction of synchronization:
>
> - random-byte-only 143.487 ± 10.932 ns/op
> - higher-precision 149.651 ± 8.438 ns/op
> - counter-based 245.036 ± 2.943 ns/op
>
> The best balance here might be to employ a higher-precision implementation as
On Thu, 29 May 2025 18:30:59 GMT, Roger Riggs wrote:
>> In terms of using another clock it could open up possiblities of passing non
>> complaint time formats to the method, but maybe thats something that could
>> be mostly prevented with input validation and clear documentation i.e.
>> “times
mentation due to the introduction of synchronization:
>
> - random-byte-only 143.487 ± 10.932 ns/op
> - higher-precision 149.651 ± 8.438 ns/op
> - counter-based 245.036 ± 2.943 ns/op
>
> The best balance here might be to employ a higher-precision implementation as
On Tue, 27 May 2025 21:59:55 GMT, Roger Riggs wrote:
>> I'd say "create" instead of "retrieve" in the first line comment. (Though
>> that word is used in the other static factories).
>>
>> The "sub-millisecond precision" can't be relied upon. Its the precision that
>> gives the impression that
mentation due to the introduction of synchronization:
>
> - random-byte-only 143.487 ± 10.932 ns/op
> - higher-precision 149.651 ± 8.438 ns/op
> - counter-based 245.036 ± 2.943 ns/op
>
> The best balance here might be to employ a higher-precision implementation as
mentation due to the introduction of synchronization:
>
> - random-byte-only 143.487 ± 10.932 ns/op
> - higher-precision 149.651 ± 8.438 ns/op
> - counter-based 245.036 ± 2.943 ns/op
>
> The best balance here might be to employ a higher-precision implementation as
On Thu, 3 Jul 2025 07:03:19 GMT, Alan Bateman wrote:
>> Kieran Farrell has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> rm whitespace
>
> src/java.base/share/classes/java/util/UUID.java line 212:
>
On Wed, 2 Jul 2025 09:52:54 GMT, Raffaello Giulietti
wrote:
>> Hello Roger, that's true about the uniqueness semantics. However, from what
>> I understand of RFC-9562, on which this new API is based, I think it has
>> much stricter expectations about monotonocity (the first 48 bits) too. For
mentation due to the introduction of synchronization:
>
> - random-byte-only 143.487 ± 10.932 ns/op
> - higher-precision 149.651 ± 8.438 ns/op
> - counter-based 245.036 ± 2.943 ns/op
>
> The best balance here might be to employ a higher-precision implementation as
On Mon, 30 Jun 2025 18:19:30 GMT, Kieran Farrell wrote:
>> With the recent approval of UUIDv7
>> (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new
>> static method UUID.timestampUUID() which constructs and returns a UUID in
>> support of the
mentation due to the introduction of synchronization:
>
> - random-byte-only 143.487 ± 10.932 ns/op
> - higher-precision 149.651 ± 8.438 ns/op
> - counter-based 245.036 ± 2.943 ns/op
>
> The best balance here might be to employ a higher-precision implementation as
mentation due to the introduction of synchronization:
>
> - random-byte-only 143.487 ± 10.932 ns/op
> - higher-precision 149.651 ± 8.438 ns/op
> - counter-based 245.036 ± 2.943 ns/op
>
> The best balance here might be to employ a higher-precision implementation as
mentation due to the introduction of synchronization:
>
> - random-byte-only 143.487 ± 10.932 ns/op
> - higher-precision 149.651 ± 8.438 ns/op
> - counter-based 245.036 ± 2.943 ns/op
>
> The best balance here might be to employ a higher-precision implementation as
mentation due to the introduction of synchronization:
>
> - random-byte-only 143.487 ± 10.932 ns/op
> - higher-precision 149.651 ± 8.438 ns/op
> - counter-based 245.036 ± 2.943 ns/op
>
> The best balance here might be to employ a higher-precision implementation as
26 matches
Mail list logo
