On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato wrote:
> This is to enhance the character break analysis in `java.text.BreakIterator`
> to conform to the extended grapheme cluster boundaries defined in
> https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A
> corresponding CSR has
On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato wrote:
> This is to enhance the character break analysis in `java.text.BreakIterator`
> to conform to the extended grapheme cluster boundaries defined in
> https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A
> corresponding CSR has
On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato wrote:
> This is to enhance the character break analysis in `java.text.BreakIterator`
> to conform to the extended grapheme cluster boundaries defined in
> https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A
> corresponding CSR has
On Wed, 24 Aug 2022 23:48:36 GMT, Smita Kamath wrote:
>> 8289552: Make intrinsic conversions between bit representations of half
>> precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Updated
COWAL::replaceAll is the method that allows you to compose read operations
under the internal lock. For example, swap can be built with a stateful
UnaryOperator.
private static void swap(List l, int i, int j) {
l.replaceAll(new UnaryOperator() {
int cursor;
On Wed, 24 Aug 2022 23:48:36 GMT, Smita Kamath wrote:
>> 8289552: Make intrinsic conversions between bit representations of half
>> precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Updated
On Wed, 24 Aug 2022 23:48:36 GMT, Smita Kamath wrote:
>> 8289552: Make intrinsic conversions between bit representations of half
>> precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Updated
> 8289552: Make intrinsic conversions between bit representations of half
> precision values and floats
Smita Kamath has updated the pull request incrementally with one additional
commit since the last revision:
Updated copyright comment
-
Changes:
- all:
> 8289552: Make intrinsic conversions between bit representations of half
> precision values and floats
Smita Kamath has updated the pull request incrementally with one additional
commit since the last revision:
Updated test cases as per review comments
-
Changes:
- all:
On Wed, 24 Aug 2022 23:05:34 GMT, Smita Kamath wrote:
>> 8289552: Make intrinsic conversions between bit representations of half
>> precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Updated test
On Wed, 24 Aug 2022 21:03:53 GMT, Smita Kamath wrote:
>> 8289552: Make intrinsic conversions between bit representations of half
>> precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Addressed
> 8289552: Make intrinsic conversions between bit representations of half
> precision values and floats
Smita Kamath has updated the pull request incrementally with one additional
commit since the last revision:
Addressed review comments, updated test cases and microbenchmark
-
CopyOnWriteArrayList implements an efficient List::replaceAll so you could do
something like:
public static void main(String[] args) {
List cowl = new CopyOnWriteArrayList<>(new
String[]{"1","2","3"});
List copy = Arrays.asList(cowl.toArray(new String[0]));
On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev wrote:
> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that
> subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks
> the tests on some platforms even in the single-threaded case.
>
> They use
On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev wrote:
> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that
> subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks
> the tests on some platforms even in the single-threaded case.
>
> They use
On Wed, 24 Aug 2022 17:34:17 GMT, Daniel Fuchs wrote:
>> Not sure.
>> If the convention is to document every single `RuntimeException` that
>> methods invoked by this one could throw, then yes.
>> In other words, should `RuntimeExcpetion`s thrown deep in an invocation
>> stack be documented in
[JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that
subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks
the tests on some platforms even in the single-threaded case.
They use accumulators with binary plus as update function and using non-zero
On Wed, 24 Aug 2022 16:12:52 GMT, Raffaello Giulietti wrote:
>> src/java.base/share/classes/java/util/regex/MatchResult.java line 274:
>>
>>> 272: * might be preferable for other reasons.
>>> 273: *
>>> 274: * @since 20
>>
>> Should the method declare that it throws
On Wed, 24 Aug 2022 16:02:25 GMT, Daniel Fuchs wrote:
>> Add support for named groups to java.util.regex.MatchResult
>
> src/java.base/share/classes/java/util/regex/MatchResult.java line 274:
>
>> 272: * might be preferable for other reasons.
>> 273: *
>> 274: * @since
On Wed, 24 Aug 2022 15:48:38 GMT, Raffaello Giulietti wrote:
> Add support for named groups to java.util.regex.MatchResult
src/java.base/share/classes/java/util/regex/MatchResult.java line 274:
> 272: * might be preferable for other reasons.
> 273: *
> 274: * @since 20
Add support for named groups to java.util.regex.MatchResult
-
Commit messages:
- 8065554: MatchResult should provide values of named-capturing groups
Changes: https://git.openjdk.org/jdk/pull/1/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=1=00
Issue:
> From: "Ethan McCue"
> To: "Remi Forax"
> Cc: "John Hendrikx" , "core-libs-dev"
>
> Sent: Wednesday, August 24, 2022 4:27:01 PM
> Subject: Re: Proposal: Collection mutability marker interfaces
>> so it's perhaps better to call add() inside a try/catch on
> > UnsupportedOperationException.
>
> Safety-wise, taking transferring ownership is fraught
True, or at the very least a true-ism we generally accept.
But that's still a deliberate choice to make that makes a performance
tradeoff. The risk of misuse is proportional always to the exposure of and
audience of the api.
On Wed, Aug
> so it's perhaps better to call add() inside a try/catch on
UnsupportedOperationException.
As much as sin is wrong, sketching out what that might look like... forgive
the toyness of the example
final class Ex {
private Ex() {}
/*
* Adds the odd numbers from 1 to 10 to the List
Hi,
Safety-wise, taking transferring ownership is fraught, the new owner
can't be certain that the original owner hasn't kept a reference to it
or to its implementation and might be mucking around with it behind the
new owners back.
Its cleaner to design the APIs to be defensive, either the
> From: "Ethan McCue"
> To: "John Hendrikx"
> Cc: "core-libs-dev"
> Sent: Wednesday, August 24, 2022 3:38:26 PM
> Subject: Re: Proposal: Collection mutability marker interfaces
> A use case that doesn't cover is adding to a collection.
> Say as part of a method's contract you state that you
A use case that doesn't cover is adding to a collection.
Say as part of a method's contract you state that you take ownership of a
List. You aren't going to copy even if the list is mutable.
Later on, you may want to add to the list. Add is supported on ArrayList so
you don't need to copy and
Would it be an option to not make the receiver responsible for the
decision whether to make a copy or not? Instead put this burden (using
default methods) on the various collections?
If List/Set/Map had a method like this:
List immutableCopy(); // returns a (shallow) immutable copy if
On Wed, 24 Aug 2022 06:17:19 GMT, Alan Bateman wrote:
> I can't imagine a subclass of DataInputStream setting 'in' to null. If it
> handles async close then it's possible that it replaces it with an input
> stream where read throws IOException unconditionally. This is why the
> original patch
On Tue, 23 Aug 2022 18:57:07 GMT, Сергей Цыпанов wrote:
> Suppose we have a scenario where `in` is replaced asynchronously in one of
> implementations and the implementation is passed into constructor of
> `DataInputStream`. In this case the patched code is less NPE-vulnerable,
> isn't it?
I
30 matches
Mail list logo
