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.
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
