not

{@code

Can we upgrade this to a snippet?

src/java.base/share/classes/java/util/SortedSet.java line 303:

> 301:      * @since 20
> 302:      */
> 303:     default E removeFirst() {

Should removeFirst/removeLast be overridden in NavigableSet with a new default implementation like:

    if (this.isEmpty()) {
        throw new NoSuchElementException();
    }
    return this.pollFirst();

which is probably slightly more efficient?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1253174627
PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1302239328
PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1475519496
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012461962
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012462289
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1139631921
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1013372259


From smarks at openjdk.org  Mon Mar 20 23:44:54 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:44:54 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: <_buWu3J8JtJ9JaIzoHAhQXkkmK7GZAFYfOTAo_EoO08=.23d0f03c-af2d-4655-a433-4574d9277c05@github.com>

On Wed, 21 Sep 2022 04:01:13 GMT, Chen Liang  wrote:

>> PR for Sequenced Collections implementation.
>
> Since we added reversal to deque, can we add notes to a few Collections APIs like `Collections::asLifoQueue` about this newer alternative? Also on using `reverse` on the list view than actually reversing a whole list.
> 
> In addition, the new methods should have `@since 20` tags, such as on `LinkedList::reversed`, `SortedSet::addFirst`. Other similar methods are version-tagged, like `Collection::spliterator` or `Method::getParameterCount`.

@liach 

> Since we added reversal to deque, can we add notes to a few Collections APIs like `Collections::asLifoQueue` about this newer alternative? Also on using `reverse` on the list view than actually reversing a whole list.
> 
> In addition, the new methods should have `@since 20` tags, such as on `LinkedList::reversed`, `SortedSet::addFirst`. Other similar methods are version-tagged, like `Collection::spliterator` or `Method::getParameterCount`.

Good points. I've added a API notes to asLifeQueue and reverse, and I've added a bunch of @since tags. Let me know if you find other places that need them.

> Is there a particular reason we define poll (null on empty) in SequencedMap but remove (NSEE on empty) in SequencedCollection?
> 
> I understand that SequencedCollection doesn't want to be null-ambiguous, and map entries are non-null so poll there is not ambiguous. But I still think using remove for both look more consistent.

@liach 

> Is there a particular reason we define poll (null on empty) in SequencedMap but remove (NSEE on empty) in SequencedCollection?
> 
> I understand that SequencedCollection doesn't want to be null-ambiguous, and map entries are non-null so poll there is not ambiguous. But I still think using remove for both look more consistent.

Yes, this is definitely an asymmetry. I did it this way to avoid proliferation of new methods, so I just promoted existing ones from NavigableMap into SequencedMap. But I might take another swing at this and see if there's a way to get throwing versions into SequencedMap. The problem is that `firstKey` throws if empty but `firstEntry` returns null if empty. So to make things consistently throwing, we'd need to add `getFirst/LastEntry` and `removeFirst/LastEntry` to SequencedMap (and probably get rid of some of the other methods). This would make SequencedMap and probably LinkedHashMap fairly nice, but it would clutter up NavigableMap.

> Just curious, will sequenced collections be delivered directly or will it incubate/preview first?

No plans to preview. (If it were for preview, the JEP would state that prominently.)

> src/java.base/share/classes/java/util/Collections.java line 1248:
> 
>> 1246:      * @param  s the set for which an unmodifiable view is to be returned.
>> 1247:      * @return an unmodifiable view of the specified sequenced set.
>> 1248:      */
> 
> Suggestion:
> 
>      * @since 20
>      */
> 
> The last one was misplaced.

Oops, good catch. Will fix.

> src/java.base/share/classes/java/util/Collections.java line 5980:
> 
>> 5978:      * an eviction policy, which is not possible with a {@code LinkedHashSet}.
>> 5979:      *
>> 5980:      * {@code
> 
> Can we upgrade this to a snippet?

At some point yes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1301524326
PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1304414879
PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1476757813
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1014575871
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1140749658


From duke at openjdk.org  Mon Mar 20 23:44:54 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 20 Mar 2023 23:44:54 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <_buWu3J8JtJ9JaIzoHAhQXkkmK7GZAFYfOTAo_EoO08=.23d0f03c-af2d-4655-a433-4574d9277c05@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <_buWu3J8JtJ9JaIzoHAhQXkkmK7GZAFYfOTAo_EoO08=.23d0f03c-af2d-4655-a433-4574d9277c05@github.com>
Message-ID: <5ycXBFbEmUgNzCNXu4EO8Cu4HuPAFafv87Tjh4E8T38=.83f346af-3604-42d4-a7a8-1f9622e06faa@github.com>

On Sat, 5 Nov 2022 05:44:42 GMT, Stuart Marks  wrote:

>> Is there a particular reason we define poll (null on empty) in SequencedMap but remove (NSEE on empty) in SequencedCollection?
>> 
>> I understand that SequencedCollection doesn't want to be null-ambiguous, and map entries are non-null so poll there is not ambiguous. But I still think using remove for both look more consistent.
>
> @liach 
> 
>> Is there a particular reason we define poll (null on empty) in SequencedMap but remove (NSEE on empty) in SequencedCollection?
>> 
>> I understand that SequencedCollection doesn't want to be null-ambiguous, and map entries are non-null so poll there is not ambiguous. But I still think using remove for both look more consistent.
> 
> Yes, this is definitely an asymmetry. I did it this way to avoid proliferation of new methods, so I just promoted existing ones from NavigableMap into SequencedMap. But I might take another swing at this and see if there's a way to get throwing versions into SequencedMap. The problem is that `firstKey` throws if empty but `firstEntry` returns null if empty. So to make things consistently throwing, we'd need to add `getFirst/LastEntry` and `removeFirst/LastEntry` to SequencedMap (and probably get rid of some of the other methods). This would make SequencedMap and probably LinkedHashMap fairly nice, but it would clutter up NavigableMap.

@stuart-marks
> The problem is that `firstKey` throws if empty but `firstEntry` returns null if empty.

That?s?because there?s?no?way for?`firstKey` to?distinguish `null` as?meaning an?`Entry` where?`getKey()` returns?`null`, and?`null` meaning?no?mapping.

Whereas?with `firstEntry`, `null`?can?only be?returned when?the?map is?empty, because?a?`null`?key mapped?to?some?value would?return `Entry[key=null,?value=?]`.

--------------------------------------------------------------------------------

Another?way to?think about?it is?that the?default?implementation of?`firstKey()`?does:

default K firstKey() {
	return this.firstEntry().getKey();
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1304500566


From smarks at openjdk.org  Mon Mar 20 23:44:55 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:44:55 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <5ycXBFbEmUgNzCNXu4EO8Cu4HuPAFafv87Tjh4E8T38=.83f346af-3604-42d4-a7a8-1f9622e06faa@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <_buWu3J8JtJ9JaIzoHAhQXkkmK7GZAFYfOTAo_EoO08=.23d0f03c-af2d-4655-a433-4574d9277c05@github.com>
 <5ycXBFbEmUgNzCNXu4EO8Cu4HuPAFafv87Tjh4E8T38=.83f346af-3604-42d4-a7a8-1f9622e06faa@github.com>
Message-ID: <5kO1_VDAVk46brVemeITov9k-T9RUjWZCkYQ2KLQ0Es=.0cfd78d2-8785-42e2-9b4a-cd71efb5d0a7@github.com>

On Sat, 5 Nov 2022 11:17:04 GMT, ExE Boss  wrote:

>> @liach 
>> 
>>> Is there a particular reason we define poll (null on empty) in SequencedMap but remove (NSEE on empty) in SequencedCollection?
>>> 
>>> I understand that SequencedCollection doesn't want to be null-ambiguous, and map entries are non-null so poll there is not ambiguous. But I still think using remove for both look more consistent.
>> 
>> Yes, this is definitely an asymmetry. I did it this way to avoid proliferation of new methods, so I just promoted existing ones from NavigableMap into SequencedMap. But I might take another swing at this and see if there's a way to get throwing versions into SequencedMap. The problem is that `firstKey` throws if empty but `firstEntry` returns null if empty. So to make things consistently throwing, we'd need to add `getFirst/LastEntry` and `removeFirst/LastEntry` to SequencedMap (and probably get rid of some of the other methods). This would make SequencedMap and probably LinkedHashMap fairly nice, but it would clutter up NavigableMap.
>
> @stuart-marks
>> The problem is that `firstKey` throws if empty but `firstEntry` returns null if empty.
> 
> That?s?because there?s?no?way for?`firstKey` to?distinguish `null` as?meaning an?`Entry` where?`getKey()` returns?`null`, and?`null` meaning?no?mapping.
> 
> Whereas?with `firstEntry`, `null`?can?only be?returned when?the?map is?empty, because?a?`null`?key mapped?to?some?value would?return `Entry[key=null,?value=?]`.
> 
> --------------------------------------------------------------------------------
> 
> Another?way to?think about?it is?that the?default?implementation of?`firstKey()`?does:
> 
> default K firstKey() {
> 	return this.firstEntry().getKey();
> }

@ExE-Boss Yes, I'm aware of the problem if `firstKey` were to return null. (Didn't prevent `Map::get` from being added though.) The problem I was referring to was one of consistency. We have an uncomfortable mixture of throwing things and null-returning things. The challenge is to come up with a reasonable set of things that makes internal sense and that also fits with what's there already. This might not be possible. Thus, some tradeoffs are necessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1304678458


From sadayapalam at openjdk.org  Mon Mar 20 23:44:56 2023
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Mon, 20 Mar 2023 23:44:56 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

Please include the following fix for the langtools test "failures":

diff --git a/test/langtools/tools/javac/api/TestJavacTaskScanner.java b/test/langtools/tools/javac/api/TestJavacTaskScanner.java
index e8110396dac..8d53c3b9d6f 100644
--- a/test/langtools/tools/javac/api/TestJavacTaskScanner.java
+++ b/test/langtools/tools/javac/api/TestJavacTaskScanner.java
@@ -102,7 +102,7 @@ public class TestJavacTaskScanner extends ToolTester {
         System.out.println("#allMembers: " + numAllMembers);
 
         check(numTokens, "#Tokens", 1054);
- check(numParseTypeElements, "#parseTypeElements", 158);
+ check(numParseTypeElements, "#parseTypeElements", 170);
         check(numAllMembers, "#allMembers", 52);
     }
 diff --git a/test/langtools/tools/javac/processing/model/type/BoundsTest.java b/test/langtools/tools/javac/processing/model/type/BoundsTest.java
index b7e9121a956..c47b7a7de92 100644
--- a/test/langtools/tools/javac/processing/model/type/BoundsTest.java
+++ b/test/langtools/tools/javac/processing/model/type/BoundsTest.java
@@ -70,7 +70,7 @@ public class BoundsTest {
     };
     private static final String[] Single_supers = {
         "java.lang.Object",
- "java.util.Collection"
+ "java.util.SequencedCollection"
     };

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1306689463


From smarks at openjdk.org  Mon Mar 20 23:44:56 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:44:56 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Tue, 8 Nov 2022 06:15:48 GMT, Srikanth Adayapalam  wrote:

>> PR for Sequenced Collections implementation.
>
> Please include the following fix for the langtools test "failures": 
> 
> 
> diff --git a/test/langtools/tools/javac/api/TestJavacTaskScanner.java b/test/langtools/tools/javac/api/TestJavacTaskScanner.java
> index e8110396dac..8d53c3b9d6f 100644
> --- a/test/langtools/tools/javac/api/TestJavacTaskScanner.java
> +++ b/test/langtools/tools/javac/api/TestJavacTaskScanner.java
> @@ -102,7 +102,7 @@ public class TestJavacTaskScanner extends ToolTester {
>          System.out.println("#allMembers: " + numAllMembers);
>  
>          check(numTokens, "#Tokens", 1054);
> - check(numParseTypeElements, "#parseTypeElements", 158);
> + check(numParseTypeElements, "#parseTypeElements", 170);
>          check(numAllMembers, "#allMembers", 52);
>      }
>  diff --git a/test/langtools/tools/javac/processing/model/type/BoundsTest.java b/test/langtools/tools/javac/processing/model/type/BoundsTest.java
> index b7e9121a956..c47b7a7de92 100644
> --- a/test/langtools/tools/javac/processing/model/type/BoundsTest.java
> +++ b/test/langtools/tools/javac/processing/model/type/BoundsTest.java
> @@ -70,7 +70,7 @@ public class BoundsTest {
>      };
>      private static final String[] Single_supers = {
>          "java.lang.Object",
> - "java.util.Collection"
> + "java.util.SequencedCollection"
>      };

@sadayapalam

> Please include the following fix for the langtools test "failures":

OK, applying these patches lets the tests pass. I can include them in this PR.

The patch in TestJavacTaskScanner.java adjusts the expected number of elements from 158 to 170, but I note that the error message in the test failure is

    java.lang.Error: #parseTypeElements higher than expected; expected 158; found: 180

The test still passes with the expected value of 170, as the criterion seems to be that the actual number be within 10% of the expected number. Since the actual number is 180, though, would it be better to use 180?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1307795998


From duke at openjdk.org  Mon Mar 20 23:45:00 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 20 Mar 2023 23:45:00 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

Note?that `SortedMap::firstKey` and?`SortedMap::lastKey` can?now both?have a?default?implementation that?delegates to?`SequencedMap::firstEntry` and?`SequencedMap::lastEntry` respectively.

src/java.base/share/classes/java/util/SequencedMap.java line 343:

> 341:         return new SeqEntrySet();
> 342:     }
> 343: }

Missing trailing newline:
Suggestion:

}

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 554:

> 552:     public E removeLast() {
> 553:         synchronized (lock) {
> 554:            int size = getArray().length;

Wrong?indentation:
Suggestion:

            int size = getArray().length;

(this?would be?avoided if?the?JDK was?using the?more accessible?tabs[^1])

[^1]: prettier/prettier#7475

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 1734:

> 1732:                     it = base.listIterator(base.size());
> 1733:                 }
> 1734:             }

Storing?the?`size` in?a?field allows?`Reversed::stream().estimateSize()` to?match `Reversed::size()`:
Suggestion:

            final ListIterator it;
            final int size;

            DescendingIterator() {
                synchronized (lock) {
                    size = base.size();
                    it = base.listIterator(size);
                }
            }

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 1803:

> 1801:         public Spliterator spliterator() {
> 1802:             // TODO can probably improve this
> 1803:             return Spliterators.spliteratorUnknownSize(new DescendingIterator(), 0);

Suggestion:

            var it = new DescendingIterator();
            return Spliterators.spliterator(
                    it, it.size,
                    Spliterator.IMMUTABLE | Spliterator.ORDERED);

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1308200115
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1139871748
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1103614429
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1103615024
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1103615337


From sadayapalam at openjdk.org  Mon Mar 20 23:45:01 2023
From: sadayapalam at openjdk.org (Srikanth Adayapalam)
Date: Mon, 20 Mar 2023 23:45:01 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 
Message-ID: 

On Tue, 8 Nov 2022 20:36:40 GMT, Stuart Marks  wrote:

> @sadayapalam
> 
> > Please include the following fix for the langtools test "failures":
> 
> OK, applying these patches lets the tests pass. I can include them in this PR.
> 
> The patch in TestJavacTaskScanner.java adjusts the expected number of elements from 158 to 170, but I note that the error message in the test failure is
> 
> ```
> java.lang.Error: #parseTypeElements higher than expected; expected 158; found: 180
> ```
> 
> The test still passes with the expected value of 170, as the criterion seems to be that the actual number be within 10% of the expected number. Since the actual number is 180, though, would it be better to use 180?

Perhaps. The fudge factor seems to be implemented to prepare for a potential move downwards as well as upwards.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1308300571


From psandoz at openjdk.org  Mon Mar 20 23:45:03 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 20 Mar 2023 23:45:03 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

src/java.base/share/classes/java/util/Collections.java line 376:

> 374:      * reversed-ordered view of a list without mutating it, use the
> 375:      * {@link List#reversed List::reversed} method.
> 376:      *

Also add `@see ` reference

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1140817943


From duke at openjdk.org  Mon Mar 20 23:45:04 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 20 Mar 2023 23:45:04 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

src/java.base/share/classes/java/util/LinkedHashMap.java line 384:

> 382:             return this.put(k, v);
> 383:         } finally {
> 384:             putMode = PUT_NORM;

@stuart-marks Would it be an alternative to have an  `internalPut(mode, k, v)` so there is no need to have an internal variable which needs to be read/written multiple time per operation? ?

src/java.base/share/classes/java/util/SequencedCollection.java line 93:

> 91:      * underlying collection. Changes to the underlying collection might or might not be visible
> 92:      * in this reversed view, depending upon the implementation.
> 93:      *

@stuart-marks Perhaps an opportunity to spec it so that x == x.reversed().reversed() (i.e. unwrap on double-reverse)?

src/java.base/share/classes/java/util/SequencedCollection.java line 155:

> 153:      */
> 154:     default E getLast() {
> 155:         return this.reversed().iterator().next();

@stuart-marks Are these default implementation expected to be used (actually) in the JDK? From a performance PoV, it might make sense to not have default implementations unless strictly needed, and instead keep the code in the JavaDoc as a guideline for "worst-case" performance profile. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r987925904
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r986962055
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r987216743


From smarks at openjdk.org  Mon Mar 20 23:45:05 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:05 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Wed, 5 Oct 2022 13:30:08 GMT, Viktor Klang  wrote:

>> PR for Sequenced Collections implementation.
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 384:
> 
>> 382:             return this.put(k, v);
>> 383:         } finally {
>> 384:             putMode = PUT_NORM;
> 
> @stuart-marks Would it be an alternative to have an  `internalPut(mode, k, v)` so there is no need to have an internal variable which needs to be read/written multiple time per operation? ?

Yeah, the coupling here is rather distasteful. (Otherwise known as a quick and dirty hack.) Unfortunately the coupling between HashMap and LinkedHashMap is pretty special-purposed for exactly the intended usage modes (insertion-order and access-order). It could be improved, but it would probably require some refactoring in HashMap, which I didn't want to do right now, in order to keep the sequenced stuff separate.

> src/java.base/share/classes/java/util/SequencedCollection.java line 155:
> 
>> 153:      */
>> 154:     default E getLast() {
>> 155:         return this.reversed().iterator().next();
> 
> @stuart-marks Are these default implementation expected to be used (actually) in the JDK? From a performance PoV, it might make sense to not have default implementations unless strictly needed, and instead keep the code in the JavaDoc as a guideline for "worst-case" performance profile. ?

Good question. They might not actually be used in the JDK... but it isn't obvious! In fact some of these methods are used in the `sequencedValues()` view of `SequencedMap`. They could be used if there is a `SortedMap` implementation that doesn't implement `NavigableMap`. I don't think there are any of these in the JDK, but there are "in the wild." Yes, there are potentially performance issues with these, but I think it's valuable to have a complete set of default implementations available.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012436476
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012418175


From duke at openjdk.org  Mon Mar 20 23:45:05 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 20 Mar 2023 23:45:05 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 
Message-ID: <0qfhujWfzjkE__6vE_jZMl9RAWx8Or_SSlxTzapfFbY=.661bbf82-17fb-4080-989a-eca9f0f43765@github.com>

On Thu, 3 Nov 2022 01:56:05 GMT, Stuart Marks  wrote:

>> src/java.base/share/classes/java/util/LinkedHashMap.java line 384:
>> 
>>> 382:             return this.put(k, v);
>>> 383:         } finally {
>>> 384:             putMode = PUT_NORM;
>> 
>> @stuart-marks Would it be an alternative to have an  `internalPut(mode, k, v)` so there is no need to have an internal variable which needs to be read/written multiple time per operation? ?
>
> Yeah, the coupling here is rather distasteful. (Otherwise known as a quick and dirty hack.) Unfortunately the coupling between HashMap and LinkedHashMap is pretty special-purposed for exactly the intended usage modes (insertion-order and access-order). It could be improved, but it would probably require some refactoring in HashMap, which I didn't want to do right now, in order to keep the sequenced stuff separate.

Another?issue are?custom `LinkedHashMap`?subclasses which?override?`put(?)` to?do?input?validation, which?would get?bypassed by?`internalPut(?)`. A?better?solution to?a?private?field would?be?to?use [JEP?429: Scoped?values].

--------------------------------------------------------------------------------

That?said, using?`internalPut(?)` for?the?case where?`getClass() ==?LinkedHashMap.class` would?probably?be?fine.

[JEP?429: Scoped?values]: https://openjdk.org/jeps/429

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012574601


From smarks at openjdk.org  Mon Mar 20 23:45:06 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:06 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <0qfhujWfzjkE__6vE_jZMl9RAWx8Or_SSlxTzapfFbY=.661bbf82-17fb-4080-989a-eca9f0f43765@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 
 <0qfhujWfzjkE__6vE_jZMl9RAWx8Or_SSlxTzapfFbY=.661bbf82-17fb-4080-989a-eca9f0f43765@github.com>
Message-ID: <3z3hE-o5561CBnP96pc-NvOUIBo29NhCFb9AnFynU6Y=.6923d115-34f4-494b-989d-7d9d40ab1424@github.com>

On Thu, 3 Nov 2022 07:41:05 GMT, ExE Boss  wrote:

>> Yeah, the coupling here is rather distasteful. (Otherwise known as a quick and dirty hack.) Unfortunately the coupling between HashMap and LinkedHashMap is pretty special-purposed for exactly the intended usage modes (insertion-order and access-order). It could be improved, but it would probably require some refactoring in HashMap, which I didn't want to do right now, in order to keep the sequenced stuff separate.
>
> Another?issue are?custom `LinkedHashMap`?subclasses which?override?`put(?)` to?do?input?validation, which?would get?bypassed by?`internalPut(?)`. A?better?solution to?a?private?field would?be?to?use [JEP?429: Scoped?values].
> 
> --------------------------------------------------------------------------------
> 
> That?said, using?`internalPut(?)` for?the?case where?`getClass() ==?LinkedHashMap.class` would?probably?be?fine.
> 
> [JEP?429: Scoped?values]: https://openjdk.org/jeps/429

Input validation can't really be done in `put()`, since there are a bunch of other paths such as `computeIfAbsent()` that will insert entries without calling `put()`.

I think some judicious refactoring in HashMap to provide better support to LinkedHashMap is called for here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1014576382


From smarks at openjdk.org  Mon Mar 20 23:45:07 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:07 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Tue, 12 Apr 2022 19:55:13 GMT, Eamonn McManus  wrote:

>> PR for Sequenced Collections implementation.
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 604:
> 
>> 602:      * @return a set view of the keys contained in this map
>> 603:      */
>> 604:     public SequencedSet keySet() {
> 
> Changing the return type means that subclasses of `LinkedHashMap` that override `keySet()` will no longer compile, unless they also change the return type.

Yes. Previously compiled binaries will also throw `NoSuchMethodError` if they call `super.keySet()`. Clearly these are incompatibilities; the question is whether they are severe enough to warrant pursuing a different approach. If you have any thoughts about how to assess the severity of this change, please let me know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r848945910


From duke at openjdk.org  Mon Mar 20 23:45:07 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 20 Mar 2023 23:45:07 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 
Message-ID: <5dL_Rh5ZEG4s04eQrNZorhh2sz0K2W7SL4AxUbWmbVs=.8efd267e-bb8f-4361-aa95-1151f795fcc2@github.com>

On Tue, 12 Apr 2022 23:25:14 GMT, Stuart Marks  wrote:

>> src/java.base/share/classes/java/util/LinkedHashMap.java line 604:
>> 
>>> 602:      * @return a set view of the keys contained in this map
>>> 603:      */
>>> 604:     public SequencedSet keySet() {
>> 
>> Changing the return type means that subclasses of `LinkedHashMap` that override `keySet()` will no longer compile, unless they also change the return type.
>
> Yes. Previously compiled binaries will also throw `NoSuchMethodError` if they call `super.keySet()`. Clearly these are incompatibilities; the question is whether they are severe enough to warrant pursuing a different approach. If you have any thoughts about how to assess the severity of this change, please let me know.

Won?t?`super.keySet()` resolve to?a?bridge?method in?that?case?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r849394986


From smarks at openjdk.org  Mon Mar 20 23:45:07 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:07 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <5dL_Rh5ZEG4s04eQrNZorhh2sz0K2W7SL4AxUbWmbVs=.8efd267e-bb8f-4361-aa95-1151f795fcc2@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 
 <5dL_Rh5ZEG4s04eQrNZorhh2sz0K2W7SL4AxUbWmbVs=.8efd267e-bb8f-4361-aa95-1151f795fcc2@github.com>
Message-ID: <0BBjJX4m4R4hvGBgXI9MJYOOKRRTiH9veEigIsB4LAU=.52e87be1-9a16-494d-90d6-95559721bce5@github.com>

On Wed, 13 Apr 2022 11:53:52 GMT, ExE Boss  wrote:

>> Yes. Previously compiled binaries will also throw `NoSuchMethodError` if they call `super.keySet()`. Clearly these are incompatibilities; the question is whether they are severe enough to warrant pursuing a different approach. If you have any thoughts about how to assess the severity of this change, please let me know.
>
> Won?t?`super.keySet()` resolve to?a?bridge?method in?that?case?

Oh yes, in this case it might resolve to a bridge method, and it might actually work. In this case. However, the compatibility matrix for covariant overrides and bridge methods is quite complex; see

https://mail.openjdk.java.net/pipermail/core-libs-dev/2012-February/009119.html

for why we decided not to add covariant `clone` overrides. Similar issues might arise here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r849809038


From smarks at openjdk.org  Mon Mar 20 23:45:07 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:07 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <0BBjJX4m4R4hvGBgXI9MJYOOKRRTiH9veEigIsB4LAU=.52e87be1-9a16-494d-90d6-95559721bce5@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 
 <5dL_Rh5ZEG4s04eQrNZorhh2sz0K2W7SL4AxUbWmbVs=.8efd267e-bb8f-4361-aa95-1151f795fcc2@github.com>
 <0BBjJX4m4R4hvGBgXI9MJYOOKRRTiH9veEigIsB4LAU=.52e87be1-9a16-494d-90d6-95559721bce5@github.com>
Message-ID: 

On Wed, 13 Apr 2022 19:08:58 GMT, Stuart Marks  wrote:

>> Won?t?`super.keySet()` resolve to?a?bridge?method in?that?case?
>
> Oh yes, in this case it might resolve to a bridge method, and it might actually work. In this case. However, the compatibility matrix for covariant overrides and bridge methods is quite complex; see
> 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2012-February/009119.html
> 
> for why we decided not to add covariant `clone` overrides. Similar issues might arise here.

For what it's worth, I've done a detailed compatibility analysis of the cases here, and I've decided that adding covariant overrides for keySet/values/entrySet is too dangerous. See the full analysis in the documents attached to the CSR request:

https://bugs.openjdk.org/browse/JDK-8266572

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012392883


From duke at openjdk.org  Mon Mar 20 23:45:08 2023
From: duke at openjdk.org (Grzegorz Piwowarek)
Date: Mon, 20 Mar 2023 23:45:08 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <8d7p_kGQQJWXOAkBjVpLuSPBRbY9R7Gs_xpku798Aw8=.44b4465c-cb91-4395-91ab-486fc8022f13@github.com>

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

src/java.base/share/classes/java/util/SequencedCollection.java line 84:

> 82:      * the iterator() method, calls next() on it and returns the result.
> 83:      */
> 84:     default E getFirst() {

Too bad there's no `Optional` here, but I assume that's because you don't want to mix two approaches within a class hierarchy?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r956666157


From smarks at openjdk.org  Mon Mar 20 23:45:08 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:08 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <8d7p_kGQQJWXOAkBjVpLuSPBRbY9R7Gs_xpku798Aw8=.44b4465c-cb91-4395-91ab-486fc8022f13@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <8d7p_kGQQJWXOAkBjVpLuSPBRbY9R7Gs_xpku798Aw8=.44b4465c-cb91-4395-91ab-486fc8022f13@github.com>
Message-ID: 

On Sun, 28 Aug 2022 05:45:54 GMT, Grzegorz Piwowarek  wrote:

>> PR for Sequenced Collections implementation.
>
> src/java.base/share/classes/java/util/SequencedCollection.java line 84:
> 
>> 82:      * the iterator() method, calls next() on it and returns the result.
>> 83:      */
>> 84:     default E getFirst() {
> 
> Too bad there's no `Optional` here, but I assume that's because you don't want to mix two approaches within a class hierarchy?

I wanted to make `getFirst` et. al. be identical to the methods already in `Deque`, to avoid proliferation of methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r957518311


From duke at openjdk.org  Mon Mar 20 23:45:08 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 20 Mar 2023 23:45:08 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: <9_34ZKelWdc1dC_aPGVB9zo4caFdMa2xPmnjlzd94CY=.491ae57b-b117-4372-a71f-4669e2fd3545@github.com>

On Tue, 4 Oct 2022 14:43:44 GMT, Viktor Klang  wrote:

>> PR for Sequenced Collections implementation.
>
> src/java.base/share/classes/java/util/SequencedCollection.java line 93:
> 
>> 91:      * underlying collection. Changes to the underlying collection might or might not be visible
>> 92:      * in this reversed view, depending upon the implementation.
>> 93:      *
> 
> @stuart-marks Perhaps an opportunity to spec it so that x == x.reversed().reversed() (i.e. unwrap on double-reverse)?

@stuart-marks What are examples of cases where it wouldn't be reasonable: https://github.com/openjdk/jdk/pull/7387/files#diff-2b261a88d9ed30893d24186a36ef500d284d82e8f345591fc6c44ed5ae15da4fR161 ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r988048079


From smarks at openjdk.org  Mon Mar 20 23:45:08 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:08 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <9_34ZKelWdc1dC_aPGVB9zo4caFdMa2xPmnjlzd94CY=.491ae57b-b117-4372-a71f-4669e2fd3545@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <9_34ZKelWdc1dC_aPGVB9zo4caFdMa2xPmnjlzd94CY=.491ae57b-b117-4372-a71f-4669e2fd3545@github.com>
Message-ID: 

On Wed, 5 Oct 2022 15:15:05 GMT, Viktor Klang  wrote:

>> src/java.base/share/classes/java/util/SequencedCollection.java line 93:
>> 
>>> 91:      * underlying collection. Changes to the underlying collection might or might not be visible
>>> 92:      * in this reversed view, depending upon the implementation.
>>> 93:      *
>> 
>> @stuart-marks Perhaps an opportunity to spec it so that x == x.reversed().reversed() (i.e. unwrap on double-reverse)?
>
> @stuart-marks What are examples of cases where it wouldn't be reasonable: https://github.com/openjdk/jdk/pull/7387/files#diff-2b261a88d9ed30893d24186a36ef500d284d82e8f345591fc6c44ed5ae15da4fR161 ?

I had to uncomment that line to figure out what broke. :-) Turns out `TreeSet.reversed().reversed()` doesn't return the original TreeSet. This is because `descendingSet().descendingSet()` doesn't unwrap, and neither does TreeMap's `descendingMap().descendingMap()`. I don't know what this wasn't done in the first place. Nonetheless, since unwrapping isn't done in the underlying implementation, it doesn't seem reasonable for the specification to require it be done. Furthermore this enables `reversed()` to be implemented as a default method that simply delegates to the respective `descending*()` method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1012410605


From smarks at openjdk.org  Mon Mar 20 23:45:08 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:45:08 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Fri, 17 Mar 2023 07:30:12 GMT, ExE Boss  wrote:

>> PR for Sequenced Collections implementation.
>
> src/java.base/share/classes/java/util/SequencedMap.java line 343:
> 
>> 341:         return new SeqEntrySet();
>> 342:     }
>> 343: }
> 
> Missing trailing newline:
> Suggestion:
> 
> }

will fix

> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 554:
> 
>> 552:     public E removeLast() {
>> 553:         synchronized (lock) {
>> 554:            int size = getArray().length;
> 
> Wrong?indentation:
> Suggestion:
> 
>             int size = getArray().length;
> 
> (this?would be?avoided if?the?JDK was?using the?more accessible?tabs[^1])
> 
> [^1]: prettier/prettier#7475

Thanks, will fix.

> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 1803:
> 
>> 1801:         public Spliterator spliterator() {
>> 1802:             // TODO can probably improve this
>> 1803:             return Spliterators.spliteratorUnknownSize(new DescendingIterator(), 0);
> 
> Suggestion:
> 
>             var it = new DescendingIterator();
>             return Spliterators.spliterator(
>                     it, it.size,
>                     Spliterator.IMMUTABLE | Spliterator.ORDERED);

Thanks, but I have some pending work to redo most if not all of the spliterators.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1140749575
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1104931273
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1104931560


From smarks at openjdk.org  Mon Mar 20 23:47:38 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 20 Mar 2023 23:47:38 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <8TgBVKlRLLYybAvEbt7Pz3Ucs_-jPNo8HckE3am8i5I=.84e4c3e0-7060-4d26-bd5e-945e6a60f707@github.com>

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

[JEP 431](https://openjdk.org/jeps/431) is now Targeted to JDK 21. Hooray! It thus seems as good a time as any to mark this PR as ready for review. Currently I'm focusing on getting the specification finished so I can then update and finalize the [CSR](https://bugs.openjdk.org/browse/JDK-8266572) which is the last remaining hurdle before integration. I'd thus appreciate comments that focus on the specifications. See a recent specdiff:

https://cr.openjdk.org/~smarks/collections/specdiff-sequenced-20230316/overview-summary.html

or you can comment on the doc comments in the code changes themselves.

Of course if there implementation or other comments, feel free to post them, though I may postpone them until after the CSR is completed and possibly even after the initial integration. If I do the latter I'll track changes as separate bug reports (and thus separate PRs).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1477093137


From liach at openjdk.org  Tue Mar 21 00:56:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 00:56:53 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

Just curious, does sequenced collection specify if add simulates addLast if addition supports custom ordering? I wish to have efficient reversible batch addition operations available, like ordered versions of addAll.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1477097626


From psadhukhan at openjdk.org  Tue Mar 21 03:17:50 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 21 Mar 2023 03:17:50 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v6]
In-Reply-To: 
References: 
 
 
 
 <87N00fvqW3bj33-vGIWck9XK1F8tcjMEUGnG5xOsVGc=.dbe68878-0f25-429f-8579-786d9de2fbf8@github.com>
 
 
Message-ID: 

On Fri, 17 Mar 2023 18:23:33 GMT, Damon Nguyen  wrote:

>> I guess now in JDK with your testcase, popup button are shown opposite to what native components shows ie editable combobox shows non-editable pop-up button and non-editable combobox shows editable pull-down button
>> 
>>  
>> ![image](https://user-images.githubusercontent.com/43534309/225811385-0aea444e-80b3-4608-8a19-31abddaa4501.png)
>> 
>> whereas in native for non-editable one we have pop-up
>> ![image](https://user-images.githubusercontent.com/43534309/225811657-62c3f8c5-9ed2-4ad9-b291-48b55569c79b.png)
>> and for editable we have pull-down
>> ![image](https://user-images.githubusercontent.com/43534309/225812101-9939bd87-d3ef-4f1c-ac32-c5bd37ac647e.png)
>
> This is because the test is set to test for isPopDown set to true, which changes the button appearance for non-editable to be a single down arrow. With this set to false, the button would match native. I have updated the test to test the native instead. Thanks.
> 
> For the editable comboboxes, the only button that is supported is the up and down arrow one shown. So, this one cannot be changed.
> 
> They now show as: 
> 

The above Apple statement only talks about non-editable combobox but I guess, we have issue, as you told, with editable combobox buttons which as per this code relies on BUTTON_COMBO_BOX state, so I guess we should ask Apple about BUTTON_POP_DOWN support for editable one or any other alternative via JRS

https://github.com/openjdk/jdk/blob/c09f83ec25749af349fb5609e3641b5bb6d34072/src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java#L144-L157

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12750#discussion_r1142853539


From smarks at openjdk.org  Tue Mar 21 03:36:57 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 21 Mar 2023 03:36:57 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

(Heh, it looks like a whole bunch of old PR comments from when it was in draft state just got replayed to the mailing lists.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1477235039


From smarks at openjdk.org  Tue Mar 21 03:46:58 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 21 Mar 2023 03:46:58 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Mon, 20 Mar 2023 23:52:11 GMT, Chen Liang  wrote:

>> PR for Sequenced Collections implementation.
>
> Just curious, does sequenced collection specify if add simulates addLast if addition supports custom ordering? I wish to have efficient reversible batch addition operations available, like ordered versions of addAll.

@liach 

> Just curious, does sequenced collection specify if add simulates addLast if addition supports custom ordering? I wish to have efficient reversible batch addition operations available, like ordered versions of addAll.

Well the specs say what they say. For List, Deque, and LinkedHashSet, the add(E) method adds at the end. The addAll(Collection) method is specified to honor the iteration order (really, encounter order) of the argument, and they all add at the end. (But Deque.addAll is specified in terms of addLast.) If some other existing collection defines add(E) to insert at some custom location, then addAll(Collection) will need to specify what it does. Converting that collection to be sequenced doesn't necessarily change that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1477240323


From duke at openjdk.org  Tue Mar 21 05:10:24 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 21 Mar 2023 05:10:24 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

Jeremy has updated the pull request incrementally with one additional commit since the last revision:

  8303950: approaching using double-buffer approach instead
  
  The PaintManager explicitly states that its for Swing components. This pulls some logic out of PaintManager that can be applied to generic awt.Components and introduces the AWTPaintManager super class.
  
  The broad goal here is to take advantage of double-buffering AND avoid copying and pasting the hard work that the PaintManager already took care (regarding tiling, scaling, and looping attempts to use VolatileImages).
  
  This is response to ongoing PR discussions; see https://github.com/openjdk/jdk/pull/12993#issuecomment-1470887449

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12993/files
  - new: https://git.openjdk.org/jdk/pull/12993/files/6594b548..6a3a9b42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=00-01

  Stats: 206 lines in 3 files changed: 81 ins; 98 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/12993.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12993/head:pull/12993

PR: https://git.openjdk.org/jdk/pull/12993


From psadhukhan at openjdk.org  Tue Mar 21 09:10:54 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 21 Mar 2023 09:10:54 GMT
Subject: RFR: 6245410: javax.swing.text.html.CSS.Attribute: BACKGROUND_POSITION
 is not w3c spec compliant
Message-ID: 

[CSS spec for background-position](https://www.w3.org/TR/CSS22/colors.html#propdef-background-position)
mention the initial value should be "0% 0%" but JDK has the value as "null".
Rectified the spec violation. 
No regression is seen in client tests..

-------------

Commit messages:
 - fix
 - 6245410: javax.swing.text.html.CSS.Attribute: BACKGROUND_POSITION is not w3c spec compliant

Changes: https://git.openjdk.org/jdk/pull/13114/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13114&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6245410
  Stats: 43 lines in 2 files changed: 42 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13114/head:pull/13114

PR: https://git.openjdk.org/jdk/pull/13114


From mbaesken at openjdk.org  Tue Mar 21 09:17:09 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 21 Mar 2023 09:17:09 GMT
Subject: RFR: JDK-8304334:
 java/awt/color/ICC_ColorSpace/ToFromCIEXYZRoundTrip.java times out on slow
 platforms
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Mar 2023 09:08:56 GMT, Matthias Baesken  wrote:

> The ToFromCIEXYZRoundTrip test times out on slow platforms , especially when (fast)debug binaries are used.
> This was observed on Alpine Linux and AIX in our automated tests.  Setting an increased timeout for the test helps to reduce test errors because of timeouts.

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13073#issuecomment-1477492219


From mbaesken at openjdk.org  Tue Mar 21 09:17:10 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 21 Mar 2023 09:17:10 GMT
Subject: Integrated: JDK-8304334:
 java/awt/color/ICC_ColorSpace/ToFromCIEXYZRoundTrip.java times out on slow
 platforms
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Mar 2023 09:08:56 GMT, Matthias Baesken  wrote:

> The ToFromCIEXYZRoundTrip test times out on slow platforms , especially when (fast)debug binaries are used.
> This was observed on Alpine Linux and AIX in our automated tests.  Setting an increased timeout for the test helps to reduce test errors because of timeouts.

This pull request has now been integrated.

Changeset: c65bb2c5
Author:    Matthias Baesken 
URL:       https://git.openjdk.org/jdk/commit/c65bb2c58e0328cec83ebfa5408b5176f8639d14
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8304334: java/awt/color/ICC_ColorSpace/ToFromCIEXYZRoundTrip.java times out on slow platforms

Reviewed-by: lucy, serb, prr

-------------

PR: https://git.openjdk.org/jdk/pull/13073


From liach at openjdk.org  Tue Mar 21 12:42:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 12:42:06 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

I am interested in the optimization potential of `arraylist.reversed().addAll()` and similar batch operations. Though reverse list/deque views are a good start, I still wish to see customized implementations for `reversed` to perform `addAll` `removeIf` efficiently.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1477768549


From duke at openjdk.org  Tue Mar 21 14:22:41 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 21 Mar 2023 14:22:41 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

Jeremy has updated the pull request incrementally with one additional commit since the last revision:

  8303950: addressing artifacts observed in RepaintManagerFPUIScaleTest
  
  When I resized the window in the RepaintManagerFPUIScaleTest: I saw lots of random patches of misplaced pixels.
  
  I assume this is because the RepaintManager could now call AWTPaintManager#paint(..) recursively, which means each invocation could grab the cached VolatileImage returned by getVolatileOffscreenBuffer. As a test: I tried making getVolatileOffscreenBuffer always return a new image, and that resolved the artifacts.
  
  This change avoids the recursion with a new helper method. This logic is similar to checking JComponent#getFlag(ANCESTOR_USING_BUFFER) , except that can't help identify recursion when the outermost call is coming from a Component like a Window.
  
  To my knowledge this recursion can only ever happen when the outermost call is a non-Swing component and the innermost call is a Swing component. (And there should only ever be one layer of recursion.)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12993/files
  - new: https://git.openjdk.org/jdk/pull/12993/files/6a3a9b42..960fd176

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=01-02

  Stats: 70 lines in 2 files changed: 35 ins; 10 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/12993.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12993/head:pull/12993

PR: https://git.openjdk.org/jdk/pull/12993


From aivanov at openjdk.org  Tue Mar 21 16:42:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Mar 2023 16:42:52 GMT
Subject: RFR: 6245410: javax.swing.text.html.CSS.Attribute:
 BACKGROUND_POSITION is not w3c spec compliant
In-Reply-To: 
References: 
Message-ID: <1BKXX_wINfZAJwSKsqans5wq_dfv_UhWw9gpez26nvc=.03e7e9a1-7381-4be2-bd90-42d74201923b@github.com>

On Tue, 21 Mar 2023 08:31:29 GMT, Prasanta Sadhukhan  wrote:

> [CSS spec for background-position](https://www.w3.org/TR/CSS22/colors.html#propdef-background-position)
> mention the initial value should be "0% 0%" but JDK has the value as "null".
> Rectified the spec violation. 
> No regression is seen in client tests..

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/text/html/CSS/CSSAttributeComplianceTest.java line 32:

> 30: import javax.swing.text.html.CSS.Attribute;
> 31: 
> 32: public class CSSAttributeComplianceTest{

Suggestion:

public class CSSAttributeComplianceTest {


There's a missing space before the opening brace.

I wonder whether the test is supposed to be extendable? I mean with other attributes. If it's the case, then the suggested name is fine. If it's only for `background-position` attribute, then `BackgroundPositionAttributeTest` could be a better alternative. (The `CSS` part is in the path, so I decided to drop it from the class name.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/13114#pullrequestreview-1350945481
PR Review Comment: https://git.openjdk.org/jdk/pull/13114#discussion_r1143696386


From aivanov at openjdk.org  Tue Mar 21 16:47:32 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Mar 2023 16:47:32 GMT
Subject: RFR: 6245410: javax.swing.text.html.CSS.Attribute:
 BACKGROUND_POSITION is not w3c spec compliant
In-Reply-To: 
References: 
Message-ID: <7KnNQ8ZCi6GbH4vFU282Ej-slFQLruUF_kxLjnn4kos=.c0969609-9d2a-4723-9964-f22020951fc9@github.com>

On Tue, 21 Mar 2023 08:31:29 GMT, Prasanta Sadhukhan  wrote:

> [CSS spec for background-position](https://www.w3.org/TR/CSS22/colors.html#propdef-background-position)
> mention the initial value should be "0% 0%" but JDK has the value as "null".
> Rectified the spec violation. 
> No regression is seen in client tests..

What about `CSS.Attribute.TEXT_DECORATION`? I agree it should be handled separately, but I don't see a related bug linked in JBS to address the second issue from the bug description.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13114#issuecomment-1478220311


From dnguyen at openjdk.org  Tue Mar 21 16:55:43 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 21 Mar 2023 16:55:43 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v6]
In-Reply-To: 
References: 
 
 
 
 <87N00fvqW3bj33-vGIWck9XK1F8tcjMEUGnG5xOsVGc=.dbe68878-0f25-429f-8579-786d9de2fbf8@github.com>
 
 
 
Message-ID: <-hwEXSpfI-6ll_DT9NFqq586qikVbl8CRaIJh3DFYcs=.72a09aa5-bf4d-416b-ac7a-80d158527bf4@github.com>

On Tue, 21 Mar 2023 03:15:08 GMT, Prasanta Sadhukhan  wrote:

>> This is because the test is set to test for isPopDown set to true, which changes the button appearance for non-editable to be a single down arrow. With this set to false, the button would match native. I have updated the test to test the native instead. Thanks.
>> 
>> For the editable comboboxes, the only button that is supported is the up and down arrow one shown. So, this one cannot be changed.
>> 
>> They now show as: 
>> 
>
> The above Apple statement only talks about non-editable combobox but I guess, we have issue, as you told, with editable combobox buttons which as per this code relies on BUTTON_COMBO_BOX state, so I guess we should ask Apple about BUTTON_POP_DOWN support for editable one or any other alternative via JRS
> 
> https://github.com/openjdk/jdk/blob/c09f83ec25749af349fb5609e3641b5bb6d34072/src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java#L144-L157

Sure, I can setup a question for clarification. Looking at the original set of questions to Apple, the dropdown button symbol was included, but wasn't answered. Must have been lost in the list of questions at the time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12750#discussion_r1143716130


From martin.pernollet at protonmail.com  Tue Mar 21 17:39:47 2023
From: martin.pernollet at protonmail.com (Martin Pernollet)
Date: Tue, 21 Mar 2023 17:39:47 +0000
Subject: JVM hang with Swing and macOS
In-Reply-To: 
References: 
 
 <6QaNotL5_WbYMK2V6YyvZYL06NOXFa4SWn10Bq8_Is_InxN5yb5RAhmgNM38JRstYPoECGbrY3wt12zCJkeoP_ab_TerDaew0QrDCy789Jg=@protonmail.com>
 
 
 
 <1108127A-4940-4240-9853-D44F5A16C28F@cbfiddle.com>
 <7f370680-e1b5-c58a-5e0c-4df79094614a@amazon.com>
 <409A29DA-FB91-42E2-BF1F-16AB4C793D69@gmail.com>
 
Message-ID: <3Z6cpEUUj9wFPGD38BGfeLvHTD3lnkpOPB8WEcVQDsFZ3-V-a67l9PtQr9-KSQLHA6PtZBbr4tf7ZilUJ1BScR0_OcW6NUFNBVxVnDMhpDE=@protonmail.com>

Hi,

Thank you Sergey, Michael and Alan.

It seams the [OGLUtilities does not exists anymore](https://github.com/openjdk/jdk/tree/master/src/java.desktop/macosx/classes/sun/java2d/opengl). Do you know if there is a replacer?

The current version of [PanamaGL](https://gitlab.com/jzy3d/panama-gl) is quite simple : it opens an opengl context, either with GLUT, either with the platform specific lib to do it (WGL on windows, GLX on Linux, CGL on macOS) and then performs offscreen rendering in a frame buffer. The result is then copied to a BufferedImage that is then [simply rendered by a Swing canvas](https://gitlab.com/jzy3d/panama-gl/-/blob/main/panama-gl-ui-swing/src/main/java/panamagl/canvas/GLCanvasSwing.java#L170). I know rendering through JAWT would be more efficient but this first step was easy to achieve in one shot for all platforms (and it works pretty well :).

Cheers,

Martin

Envoy? avec la messagerie s?curis?e [Proton Mail](https://proton.me/).

------- Original Message -------
Le lundi 20 mars 2023 ? 20:50, Sergey Bylokhov bylokhov at amazon.com a ?crit :

> On 3/20/23 12:33, Michael Hall wrote:
>
>> /*
>> * We cannot use dispatch_sync here, because it blocks the main dispatch queue.
>> * Using the main NSRunLoop allows the dispatch queue to run properly once
>> * SWT (or whatever toolkit this is needed for) kicks off it's own NSRunLoop
>> * and starts running.
>> */
>> I would think the problem is that -XrunOnFirstThread is intended for ?toolkit?s that aren?t Swing based but handle the gui and NSRunLoop as indicated themselves - like Eclipse with SWT.
>
> For debug purpose you can try to remove this option and use the sun.java2d.opengl.OGLUtilities class
> instead, it was created specifically to support the JOGL library long time ago. Note that it is not
> public and can be problematic to access right now.
>
> It would be good to know how you actually render the OGL content to Swing/AWT via the java code. We
> have only one supported mechanism to do that -> via jawt from the native code using CALayer.
>
> --
> Best regards, Sergey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dnguyen at openjdk.org  Tue Mar 21 17:52:50 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 21 Mar 2023 17:52:50 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v6]
In-Reply-To: <-hwEXSpfI-6ll_DT9NFqq586qikVbl8CRaIJh3DFYcs=.72a09aa5-bf4d-416b-ac7a-80d158527bf4@github.com>
References: 
 
 
 
 <87N00fvqW3bj33-vGIWck9XK1F8tcjMEUGnG5xOsVGc=.dbe68878-0f25-429f-8579-786d9de2fbf8@github.com>
 
 
 
 <-hwEXSpfI-6ll_DT9NFqq586qikVbl8CRaIJh3DFYcs=.72a09aa5-bf4d-416b-ac7a-80d158527bf4@github.com>
Message-ID: 

On Tue, 21 Mar 2023 16:53:15 GMT, Damon Nguyen  wrote:

>> The above Apple statement only talks about non-editable combobox but I guess, we have issue, as you told, with editable combobox buttons which as per this code relies on BUTTON_COMBO_BOX state, so I guess we should ask Apple about BUTTON_POP_DOWN support for editable one or any other alternative via JRS
>> 
>> https://github.com/openjdk/jdk/blob/c09f83ec25749af349fb5609e3641b5bb6d34072/src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java#L144-L157
>
> Sure, I can setup a question for clarification. Looking at the original set of questions to Apple, the dropdown button symbol was included, but wasn't answered. Must have been lost in the list of questions at the time.

I can also create a separate issue to address this if needed since it isn't related to this fix, only observed since editable comboBoxes are displayed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12750#discussion_r1143791816


From abhiscxk at openjdk.org  Tue Mar 21 17:52:52 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 21 Mar 2023 17:52:52 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v8]
In-Reply-To: 
References: 
 
 
Message-ID: <3Tfn4JLcM5fxP2LY3NTv6Q21u9nK2oQWWReP1Tsitbk=.ec9e22d7-394f-468d-a4d0-7344251ecc86@github.com>

On Thu, 16 Mar 2023 17:24:13 GMT, Sergey Bylokhov  wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment update
>
> test/jdk/javax/accessibility/JEditorPane/TestEditorPaneAccessibleChildCount.java line 109:
> 
>> 107:             });
>> 108:             addDelay(500);
>> 109:             int childCount2 = ac.getAccessibleChildrenCount();
> 
> note: "ac" initialized on EDT, and accessed here w/o synchronization.

@mrserb Please review the latest changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12707#discussion_r1143791968


From serb at openjdk.org  Tue Mar 21 17:59:47 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 21 Mar 2023 17:59:47 GMT
Subject: RFR: 6245410: javax.swing.text.html.CSS.Attribute:
 BACKGROUND_POSITION is not w3c spec compliant
In-Reply-To: <1BKXX_wINfZAJwSKsqans5wq_dfv_UhWw9gpez26nvc=.03e7e9a1-7381-4be2-bd90-42d74201923b@github.com>
References: 
 <1BKXX_wINfZAJwSKsqans5wq_dfv_UhWw9gpez26nvc=.03e7e9a1-7381-4be2-bd90-42d74201923b@github.com>
Message-ID: 

On Tue, 21 Mar 2023 16:39:41 GMT, Alexey Ivanov  wrote:

>> [CSS spec for background-position](https://www.w3.org/TR/CSS22/colors.html#propdef-background-position)
>> mention the initial value should be "0% 0%" but JDK has the value as "null".
>> Rectified the spec violation. 
>> No regression is seen in client tests..
>
> test/jdk/javax/swing/text/html/CSS/CSSAttributeComplianceTest.java line 32:
> 
>> 30: import javax.swing.text.html.CSS.Attribute;
>> 31: 
>> 32: public class CSSAttributeComplianceTest{
> 
> Suggestion:
> 
> public class CSSAttributeComplianceTest {
> 
> 
> There's a missing space before the opening brace.
> 
> I wonder whether the test is supposed to be extendable? I mean with other attributes. If it's the case, then the suggested name is fine. If it's only for `background-position` attribute, then `BackgroundPositionAttributeTest` could be a better alternative. (The `CSS` part is in the path, so I decided to drop it from the class name.)

Can we check that this default value will be parsed fine by some of our html component?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13114#discussion_r1143801110


From abhiscxk at openjdk.org  Tue Mar 21 18:12:41 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 21 Mar 2023 18:12:41 GMT
Subject: RFR: 6245410: javax.swing.text.html.CSS.Attribute:
 BACKGROUND_POSITION is not w3c spec compliant
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 08:31:29 GMT, Prasanta Sadhukhan  wrote:

> [CSS spec for background-position](https://www.w3.org/TR/CSS22/colors.html#propdef-background-position)
> mention the initial value should be "0% 0%" but JDK has the value as "null".
> Rectified the spec violation. 
> No regression is seen in client tests..

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1:

> 1: /*

Please update the copyright year.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13114#discussion_r1143815337


From mik3hall at gmail.com  Tue Mar 21 20:12:35 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 21 Mar 2023 15:12:35 -0500
Subject: JVM hang with Swing and macOS
In-Reply-To: <3Z6cpEUUj9wFPGD38BGfeLvHTD3lnkpOPB8WEcVQDsFZ3-V-a67l9PtQr9-KSQLHA6PtZBbr4tf7ZilUJ1BScR0_OcW6NUFNBVxVnDMhpDE=@protonmail.com>
References: 
 
 <6QaNotL5_WbYMK2V6YyvZYL06NOXFa4SWn10Bq8_Is_InxN5yb5RAhmgNM38JRstYPoECGbrY3wt12zCJkeoP_ab_TerDaew0QrDCy789Jg=@protonmail.com>
 
 
 
 <1108127A-4940-4240-9853-D44F5A16C28F@cbfiddle.com>
 <7f370680-e1b5-c58a-5e0c-4df79094614a@amazon.com>
 <409A29DA-FB91-42E2-BF1F-16AB4C793D69@gmail.com>
 
 <3Z6cpEUUj9wFPGD38BGfeLvHTD3lnkpOPB8WEcVQDsFZ3-V-a67l9PtQr9-KSQLHA6PtZBbr4tf7ZilUJ1BScR0_OcW6NUFNBVxVnDMhpDE=@protonmail.com>
Message-ID: <1C071B5D-9F5C-448E-92E5-7B36F4EC669A@gmail.com>



> On Mar 21, 2023, at 12:39 PM, Martin Pernollet  wrote:
> 
> Hi,
> 
> Thank you Sergey, Michael and Alan.
> 
> It seams the OGLUtilities does not exists anymore . Do you know if there is a replacer?
> 
> The current version of PanamaGL  is quite simple : it opens an opengl context, either with GLUT, either with the platform specific lib to do it (WGL on windows, GLX on Linux, CGL on macOS) and then performs offscreen rendering in a frame buffer. The result is then copied to a BufferedImage that is then simply rendered by a Swing canvas . I know rendering through JAWT would be more efficient but this first step was easy to achieve in one shot for all platforms (and it works pretty well :).
> 
> Cheers,
> 
> Martin
> 

Martin,

Start another java process -XstartOnMainThread that does the OpenGL part from a Swing application? One hang up there though might be that I don?t think java applications that include the java native commands are allowed in the Mac App Store. Another bug due to each command has it?s own unique CFBundleIdentifier but that identifier is always the same and Apple doesn?t allow duplicates in the App Store.

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Tue Mar 21 21:07:42 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 21 Mar 2023 21:07:42 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

Jeremy has updated the pull request incrementally with one additional commit since the last revision:

  8303950: adding unit test for legacy window behavior
  
  This test passes in the current JDK. The test criteria don't really reflect a rational expected behavior; they just reflect the current status quo.
  
  This currently fails in this JDK-8303950 branch (using the new proposed AWTPaintManager), which indicates we've changed behavior.
  
  In this case it's "window 4" that's failing. We used to get a mostly blue background, and now we're getting a background that's mostly red with a little blue. This isn't necessarily a bad thing; this failure is just documenting a change.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12993/files
  - new: https://git.openjdk.org/jdk/pull/12993/files/960fd176..bd81761a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=02-03

  Stats: 131 lines in 1 file changed: 131 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12993.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12993/head:pull/12993

PR: https://git.openjdk.org/jdk/pull/12993


From duke at openjdk.org  Tue Mar 21 21:23:44 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 21 Mar 2023 21:23:44 GMT
Subject: RFR: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 16 Mar 2023 17:27:23 GMT, Sergey Bylokhov  wrote:

>> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
>> 
>> In short:
>> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
>> 
>> I left more detailed notes here about the proposed resolution:
>> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
>> 
>> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?
>
> For the possible "synchronization" change, note that on macOS the rendering to the Window is always done via backbuffer which then blits to the CALayer. We can try to delay the blit until the window is fully rendered.

@mrserb I pushed some updates that I think approach this as you recommended.

However:
How about instead I replace this branch with this approach: https://github.com/openjdk/jdk/compare/master...mickleness:jdk:JDK-8303950-alt-3?expand=1

In both branches I also added a new test case `bug8303950_legacyWindowPaintBehavior`. This test documents a combination of 4 peculiar cases regarding window/rootpane backgrounds. This is packaged as a unit test just so we can identify when a behavior changes. So if it "fails" that really just means "something changed." It doesn't always mean "that change is bad."

In this branch `bug8303950_legacyWindowPaintBehavior` fails, because now the JRootPane's background paints on top of the Window's background.

In the `JDK-8303950-alt-3` branch (see above link) the `bug8303950_legacyWindowPaintBehavior` test passes, which means the behavior doesn't change.

At your convenience please let me know your thoughts. (And obviously I'd love to hear from Alan and anyone else who wants to chime in too.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12993#issuecomment-1478595645


From serb at openjdk.org  Tue Mar 21 21:50:33 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 21 Mar 2023 21:50:33 GMT
Subject: RFR: 8279216: Investigate implementation of premultiplied alpha in the
 Little-CMS 2.13
Message-ID: 

Support of premultiplied alpha is added to the "accelerated" code path of the CMM. It is implemented on top of the new feature added to the littlecms library in 2.13 and 2.15.

The next formats are now "supported": TYPE_INT_ARGB_PRE, TYPE_4BYTE_ABGR_PRE, and any custom images which use the ComponentColorModel+8-bit-precision like RGBApre or ApreBGR.

After this patch, we will fully support all our standard types(8-bit precision), and mostly any combinations of blits between them, having two exceptions:
 * lcms does not convert pre-alpha for transparent src if dst is opaque
 * lcms does not set correct alpha(=1.0) for transparent dst if src is opaque

Both of them are "features", so we probably need to implement a workaround someday, but for now we will use our generic/slow code.

Performance results for the ColorConvertOp.filter() for images with premultiplied alpha.

| Test | Base(avgt in us/op)  | Fix(avgt in us/op) | Improvement % |
| ------------- | ------------- | ------------- |------------- |
| 32 Threads, from=sRGB:size=10:to=CIEXYZ  | 97| 12| 708% |
| 32 Threads, from=sRGB:size=100:to=CIEXYZ  | 8 013  | 617  | 1199% |
| 32 Threads, from=sRGB:size=1000:to=CIEXYZ  | 651 838  | 104 969|  521% |
| 1 Thread, from=sRGB:size=10:to=CIEXYZ  | 21| 5|  320% |
| 1 Thread, from=sRGB:size=100:to=CIEXYZ  | 677  | 300 |  126% |
| 1 Thread, from=sRGB:size=1000:to=CIEXYZ  | 60 095  | 30 536 | 97% |

-------------

Commit messages:
 - fix for the pre-2-opeque blit
 - the test is updated to expose the bug in the patch
 - more types
 - more types to test
 - Update PremultipliedAlpha.java
 - 8279216: Investigate implementation of premultiplied alpha in the Little-CMS 2.13

Changes: https://git.openjdk.org/jdk/pull/13095/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13095&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8279216
  Stats: 431 lines in 4 files changed: 402 ins; 7 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/13095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13095/head:pull/13095

PR: https://git.openjdk.org/jdk/pull/13095


From duke at openjdk.org  Wed Mar 22 06:25:58 2023
From: duke at openjdk.org (duke)
Date: Wed, 22 Mar 2023 06:25:58 GMT
Subject: Withdrawn: 8282217: Key events (key char and key code) changed for
 Swiss keyboard
In-Reply-To: 
References: 
Message-ID: 

On Fri, 6 Jan 2023 22:07:33 GMT, Alisen Chung  wrote:

> Removed check for MapVirtualKeyEx return value causing some keys to become undefined

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11887


From jwaters at openjdk.org  Wed Mar 22 14:28:35 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 22 Mar 2023 14:28:35 GMT
Subject: RFR: 8304718: GetIntArrayElements should not be passed JNI_FALSE
Message-ID: <6GasbMg7JNmOkcVZxVB8tax5OM6Qlczo0v1OsiI1YYM=.c0c8054d-b65b-4219-9af0-6214697e96ae@github.com>

AWT passes JNI_FALSE to the JVM to avoid a copy, which is not correct since JNI has absolutely no control over whether a copy is made or not. The parameter in question is a pointer to a jboolean that the JVM sets to indicate whether it made a copy or not, which should be passed nullptr because we don't bother about the copy status of the jint

-------------

Commit messages:
 - GetIntArrayElements should not be passed JNI_FALSE

Changes: https://git.openjdk.org/jdk/pull/13140/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13140&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304718
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13140.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13140/head:pull/13140

PR: https://git.openjdk.org/jdk/pull/13140


From mbaesken at openjdk.org  Wed Mar 22 14:50:23 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 22 Mar 2023 14:50:23 GMT
Subject: RFR: JDK-8304054: Linux: NullPointerException from
 FontConfiguration.getVersion in case no fonts are installed
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 16 Mar 2023 17:19:56 GMT, Sergey Bylokhov  wrote:

> @prrace Do you know any news about possibility to bundle some free/open fonts like https://dejavu-fonts.github.io/License.html?

Hi Sergey, this might be a good idea, but as long as it is not decided, should we better track the  'bundled fonts' proposal separately for example in another JBS issue ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13045#issuecomment-1479704062


From serb at openjdk.org  Wed Mar 22 18:38:17 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 22 Mar 2023 18:38:17 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v9]
In-Reply-To: 
References: 
 
Message-ID: <6x5F-6Rd8UjfO8BWEA8aZFOKSJQX-3bt_FOH8XoXcfg=.d5ed7e4a-37aa-48c6-aabd-234c631d877c@github.com>

On Thu, 16 Mar 2023 19:11:39 GMT, Abhishek Kumar  wrote:

>> JAccessWalker was not able to show component tree correctly if we switch pages for HTML content. 
>> 
>> Observation:
>> The issue observed is that the children are not reported correct for root element when switching of pages happened. The reason behind it is that the `getAccessibleChildrenCount` API is called on the old `accessibleContext` object which return the children count as 0. Whenever we switch the page the children count is recalculated based on the root element but the `accessibleContext `object used to retrieve the child remains unchanged and due to that it return the children count 0.
>> 
>> Solution:
>> 
>> Added a condition check to create a new `accessibleContext `object to find out the children count correctly whenever we switch the pages in JEditorPane. 
>> 
>> Checked with the SwingSet2 JEditorPane demo and it reports well the component tree in JAccessWalker.
>> 
>> Steps to verify:
>> 
>> JBS contains the steps to reproduce the scenario.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Access Ui field on EDT

test/jdk/javax/accessibility/JEditorPane/TestEditorPaneAccessibleChildCount.java line 117:

> 115:             });
> 116: 
> 117:             if ((childCount1 != childCount2) &&

This version will update the childCount1/2 on EDT but then will use it in the main thread w/o synchronization.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12707#discussion_r1145254012


From abhiscxk at openjdk.org  Wed Mar 22 18:45:22 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 22 Mar 2023 18:45:22 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v9]
In-Reply-To: <6x5F-6Rd8UjfO8BWEA8aZFOKSJQX-3bt_FOH8XoXcfg=.d5ed7e4a-37aa-48c6-aabd-234c631d877c@github.com>
References: 
 
 <6x5F-6Rd8UjfO8BWEA8aZFOKSJQX-3bt_FOH8XoXcfg=.d5ed7e4a-37aa-48c6-aabd-234c631d877c@github.com>
Message-ID: 

On Wed, 22 Mar 2023 18:35:09 GMT, Sergey Bylokhov  wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Access Ui field on EDT
>
> test/jdk/javax/accessibility/JEditorPane/TestEditorPaneAccessibleChildCount.java line 117:
> 
>> 115:             });
>> 116: 
>> 117:             if ((childCount1 != childCount2) &&
> 
> This version will update the childCount1/2 on EDT but then will use it in the main thread w/o synchronization.

So, the if block should also be inside EDT as mentioned below. Right?


SwingUtilities.invokeAndWait(() -> {
                childCount2 = ac.getAccessibleChildrenCount();
            if ((childCount1 != childCount2) &&
                    (childCount1 != 0 && childCount2 != 0)) {
                System.out.println("passed");
            } else {
                System.out.println("Test1 html page accessible children" +
                        " count is: "+ childCount1);
                System.out.println("Test2 html page accessible children" +
                        " count is: "+ childCount2);
                throw new RuntimeException("getAccessibleChildrenCount" +
                        " returned wrong child count");
            }
           });

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12707#discussion_r1145260219


From abhiscxk at openjdk.org  Wed Mar 22 19:16:21 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 22 Mar 2023 19:16:21 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v9]
In-Reply-To: 
References: 
 
 <6x5F-6Rd8UjfO8BWEA8aZFOKSJQX-3bt_FOH8XoXcfg=.d5ed7e4a-37aa-48c6-aabd-234c631d877c@github.com>
 
Message-ID: 

On Wed, 22 Mar 2023 18:40:56 GMT, Abhishek Kumar  wrote:

>> test/jdk/javax/accessibility/JEditorPane/TestEditorPaneAccessibleChildCount.java line 117:
>> 
>>> 115:             });
>>> 116: 
>>> 117:             if ((childCount1 != childCount2) &&
>> 
>> This version will update the childCount1/2 on EDT but then will use it in the main thread w/o synchronization.
>
> So, the if block should also be inside EDT as mentioned below. Right?
> 
> 
> SwingUtilities.invokeAndWait(() -> {
>                 childCount2 = ac.getAccessibleChildrenCount();
>             if ((childCount1 != childCount2) &&
>                     (childCount1 != 0 && childCount2 != 0)) {
>                 System.out.println("passed");
>             } else {
>                 System.out.println("Test1 html page accessible children" +
>                         " count is: "+ childCount1);
>                 System.out.println("Test2 html page accessible children" +
>                         " count is: "+ childCount2);
>                 throw new RuntimeException("getAccessibleChildrenCount" +
>                         " returned wrong child count");
>             }
>            });

> This version will update the childCount1/2 on EDT but then will use it in the main thread w/o synchronization.

Updated the childCount1/2 to be used on EDT in stead of main thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12707#discussion_r1145289799


From abhiscxk at openjdk.org  Wed Mar 22 19:16:17 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 22 Mar 2023 19:16:17 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v10]
In-Reply-To: 
References: 
Message-ID: 

> JAccessWalker was not able to show component tree correctly if we switch pages for HTML content. 
> 
> Observation:
> The issue observed is that the children are not reported correct for root element when switching of pages happened. The reason behind it is that the `getAccessibleChildrenCount` API is called on the old `accessibleContext` object which return the children count as 0. Whenever we switch the page the children count is recalculated based on the root element but the `accessibleContext `object used to retrieve the child remains unchanged and due to that it return the children count 0.
> 
> Solution:
> 
> Added a condition check to create a new `accessibleContext `object to find out the children count correctly whenever we switch the pages in JEditorPane. 
> 
> Checked with the SwingSet2 JEditorPane demo and it reports well the component tree in JAccessWalker.
> 
> Steps to verify:
> 
> JBS contains the steps to reproduce the scenario.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Review comment update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12707/files
  - new: https://git.openjdk.org/jdk/pull/12707/files/2dec603c..0d667a0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12707&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12707&range=08-09

  Stats: 23 lines in 1 file changed: 11 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12707.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12707/head:pull/12707

PR: https://git.openjdk.org/jdk/pull/12707


From dnguyen at openjdk.org  Wed Mar 22 19:28:48 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 22 Mar 2023 19:28:48 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v7]
In-Reply-To: 
References: 
 <8oNPoVHfT1l4HElMc3p0esOCE2HifQFTawFQFcQe0Cs=.56115d14-1b53-4e46-bac8-4268cf41a347@github.com>
 
Message-ID: 

On Wed, 8 Mar 2023 06:43:42 GMT, Prasanta Sadhukhan  wrote:

> https://github.com/openjdk/jdk/blob/21a6ab1e3ea5228a31955d58fe75e5ae66d1c6cd/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java#L552-L560
> 
> You took care of `enabled `property..If the above snippet still hold significance, do we need to do the same for `orientation `property too

I tested without any additional listener for orientation and set the combo's orientation to right_to_left. It's working correctly. So, I tested the code block you referenced above and removed the code for updating orientation when `comboBox != null`. This still works correctly. So, this portion of the code that updates the orientation in SynthComboBoxRenderer may be redundant.

However, the enabled portion seems to be needed, and the additional listener added is needed to generate the correct text color.

Nimbus test with a normal comboBox and a custom comboBox (with DefaultListCellRenderer) set with orientation RTL:



Test with a disabled, normal comboBox and custom comboBox (with DefaultListCellRenderer) set with orientation RTL:


-------------

PR Comment: https://git.openjdk.org/jdk/pull/12390#issuecomment-1480136066


From smarks at openjdk.org  Wed Mar 22 22:38:52 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 22 Mar 2023 22:38:52 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Tue, 21 Mar 2023 12:39:18 GMT, Chen Liang  wrote:

> I am interested in the optimization potential of `arraylist.reversed().addAll()` and similar batch operations. Though reverse list/deque views are a good start, I still wish to see customized implementations for `reversed` to perform `addAll` `removeIf` efficiently.

OK. I took a quick look over `ReverseOrderListView` and it seems like there are some things that can be optimized there. If those aren't sufficient, then additional overrides in `ArrayList` _et al_ might be warranted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1480345189


From psadhukhan at openjdk.org  Thu Mar 23 02:52:42 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Mar 2023 02:52:42 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 17 Mar 2023 18:35:07 GMT, Damon Nguyen  wrote:

>> The issue is in Aqua L&F when an editable JComboBox with a border is used. In this case, when the comboBox is clicked for the drop-down menu to show, the drop-down menu appears at the wrong coordinates (blocking the text of the comboBox and making it unreadable).
>> 
>> This seems to have been the case for a while and a similar issue appeared recently where an editable Aqua JComboBox also had wrong positioning due to having a border.
>> 
>> This fix checks for a border and modifies the bounds to accommodate the border's size. Then the usual calculations for the comboBox popup works as expected.
>> 
>> The new headful test creates an editable comboBox with a TitledBorder and with no border. Then, it automatically clicks the comboBox to open the popup, and clicks where the position of the first selectionItem should be. Finally, it checks if the selected item is correct. This is for all L&F's and the test passes on all OS's.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Mac test to match native

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12750#pullrequestreview-1353762767


From psadhukhan at openjdk.org  Thu Mar 23 02:52:43 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Mar 2023 02:52:43 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v6]
In-Reply-To: 
References: 
 
 
 
 <87N00fvqW3bj33-vGIWck9XK1F8tcjMEUGnG5xOsVGc=.dbe68878-0f25-429f-8579-786d9de2fbf8@github.com>
 
 
 
 <-hwEXSpfI-6ll_DT9NFqq586qikVbl8CRaIJh3DFYcs=.72a09aa5-bf4d-416b-ac7a-80d158527bf4@github.com>
 
Message-ID: 

On Tue, 21 Mar 2023 17:49:25 GMT, Damon Nguyen  wrote:

>> Sure, I can setup a question for clarification. Looking at the original set of questions to Apple, the dropdown button symbol was included, but wasn't answered. Must have been lost in the list of questions at the time.
>
> I can also create a separate issue to address this if needed since it isn't related to this fix, only observed since editable comboBoxes are displayed.

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12750#discussion_r1145616237


From psadhukhan at openjdk.org  Thu Mar 23 03:02:21 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Mar 2023 03:02:21 GMT
Subject: RFR: 6245410: javax.swing.text.html.CSS.Attribute:
 BACKGROUND_POSITION is not w3c spec compliant [v2]
In-Reply-To: 
References: 
Message-ID: 

> [CSS spec for background-position](https://www.w3.org/TR/CSS22/colors.html#propdef-background-position)
> mention the initial value should be "0% 0%" but JDK has the value as "null".
> Rectified the spec violation. 
> No regression is seen in client tests..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review comment updated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13114/files
  - new: https://git.openjdk.org/jdk/pull/13114/files/38c0f1a4..1d3948f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13114&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13114&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13114/head:pull/13114

PR: https://git.openjdk.org/jdk/pull/13114


From psadhukhan at openjdk.org  Thu Mar 23 03:02:22 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Mar 2023 03:02:22 GMT
Subject: RFR: 6245410: javax.swing.text.html.CSS.Attribute:
 BACKGROUND_POSITION is not w3c spec compliant [v2]
In-Reply-To: 
References: 
 <1BKXX_wINfZAJwSKsqans5wq_dfv_UhWw9gpez26nvc=.03e7e9a1-7381-4be2-bd90-42d74201923b@github.com>
 
Message-ID: 

On Tue, 21 Mar 2023 17:57:17 GMT, Sergey Bylokhov  wrote:

>> test/jdk/javax/swing/text/html/CSS/CSSAttributeComplianceTest.java line 32:
>> 
>>> 30: import javax.swing.text.html.CSS.Attribute;
>>> 31: 
>>> 32: public class CSSAttributeComplianceTest{
>> 
>> Suggestion:
>> 
>> public class CSSAttributeComplianceTest {
>> 
>> 
>> There's a missing space before the opening brace.
>> 
>> I wonder whether the test is supposed to be extendable? I mean with other attributes. If it's the case, then the suggested name is fine. If it's only for `background-position` attribute, then `BackgroundPositionAttributeTest` could be a better alternative. (The `CSS` part is in the path, so I decided to drop it from the class name.)
>
> Can we check that this default value will be parsed fine by some of our html component?

Yes, we can extend the test in future, most probably for TEXT_DECORATION so I will keep the name same

The parsing expects the value to be in form of "% %" as can be seen here which also does the parsing and there's no regression observed in client tests

https://github.com/openjdk/jdk/blob/91f407d6fe285c44bcc25c1acdf5dc0c43be0172/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L2687-L2709

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13114#discussion_r1145619337


From psadhukhan at openjdk.org  Thu Mar 23 03:02:23 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Mar 2023 03:02:23 GMT
Subject: Integrated: 6245410: javax.swing.text.html.CSS.Attribute:
 BACKGROUND_POSITION is not w3c spec compliant
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Mar 2023 08:31:29 GMT, Prasanta Sadhukhan  wrote:

> [CSS spec for background-position](https://www.w3.org/TR/CSS22/colors.html#propdef-background-position)
> mention the initial value should be "0% 0%" but JDK has the value as "null".
> Rectified the spec violation. 
> No regression is seen in client tests..

This pull request has now been integrated.

Changeset: c4338620
Author:    Prasanta Sadhukhan 
URL:       https://git.openjdk.org/jdk/commit/c4338620b7651f4da03ce4cfddb9e5b053fddb6a
Stats:     44 lines in 2 files changed: 42 ins; 0 del; 2 mod

6245410: javax.swing.text.html.CSS.Attribute: BACKGROUND_POSITION is not w3c spec compliant

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/13114


From psadhukhan at openjdk.org  Thu Mar 23 03:08:44 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Mar 2023 03:08:44 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v7]
In-Reply-To: <8oNPoVHfT1l4HElMc3p0esOCE2HifQFTawFQFcQe0Cs=.56115d14-1b53-4e46-bac8-4268cf41a347@github.com>
References: 
 <8oNPoVHfT1l4HElMc3p0esOCE2HifQFTawFQFcQe0Cs=.56115d14-1b53-4e46-bac8-4268cf41a347@github.com>
Message-ID: <7yYwuMPLsHhXSTXtfq25zwTZLuiv0LVvlky9DMHptL0=.fd9c8d4a-4478-47d6-a2d5-318a4695ec6a@github.com>

On Thu, 2 Mar 2023 22:43:00 GMT, Damon Nguyen  wrote:

>> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
>> 
>> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
>> 
>> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
>> 
>> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug line. Add StringBuffer for fail msg

ok..

-------------

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12390#pullrequestreview-1353772340


From serb at openjdk.org  Thu Mar 23 04:20:39 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Mar 2023 04:20:39 GMT
Subject: RFR: 8304718: GetIntArrayElements should not be passed JNI_FALSE
In-Reply-To: <6GasbMg7JNmOkcVZxVB8tax5OM6Qlczo0v1OsiI1YYM=.c0c8054d-b65b-4219-9af0-6214697e96ae@github.com>
References: <6GasbMg7JNmOkcVZxVB8tax5OM6Qlczo0v1OsiI1YYM=.c0c8054d-b65b-4219-9af0-6214697e96ae@github.com>
Message-ID: 

On Wed, 22 Mar 2023 14:20:54 GMT, Julian Waters  wrote:

> AWT passes JNI_FALSE to the JVM to avoid a copy, which is not correct since JNI has absolutely no control over whether a copy is made or not. The parameter in question is a pointer to a jboolean that the JVM sets to indicate whether it made a copy or not, which should be passed nullptr because we don't bother about the copy status of the jint

There are same issue in LWCToolkit.m and awt_Robot.c.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13140#issuecomment-1480580031


From tr at openjdk.org  Thu Mar 23 05:38:44 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 23 Mar 2023 05:38:44 GMT
Subject: RFR: 8257455: javax/swing/Security/6378709/TimerHack.java and
 javax/swing/JFileChooser/4163841/AcceptAllFileFilterTest.java fails in CI
In-Reply-To: 
References: <0es3kRdwbhAbb8ZrNity1Q0fn0vhgDhy9UX17i2bkik=.4b4d9fa6-b20f-44e2-8257-4ecbe167a13e@github.com>
 
 
 
Message-ID: <1ZIzptDDOC1yrB5Asmm7p6aPlEVBtDyOimEFMfTzuSw=.4da22385-6b46-4421-b443-ccb11b0d0acc@github.com>

On Mon, 20 Mar 2023 19:13:30 GMT, Sergey Bylokhov  wrote:

>> @mrserb U had mentioned about reproducing the bug 5 out of 2000 times in jbs, any chance u remember where did u run? On physical/OCI Oracle linux CI system or any other?
>
> The JBS issue is closed. "?? Failed to retrieve information on issue 8257455"

Yeah, since these tests are in closed repo.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13012#discussion_r1145699175


From psadhukhan at openjdk.org  Thu Mar 23 06:24:24 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Mar 2023 06:24:24 GMT
Subject: RFR: 4130823: Not painting focus when the radio button has only icon
Message-ID: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com>

Although the issue here is asking about not painting focus when it has icon, however it seems Windows does not draw focus rect for radiobutton at all so instead of closing this as "Not an issue" it is made to not draw the focusrect even when there is text

This is what can be seen in windows system setting

![systemsetting-nofocusrect](https://user-images.githubusercontent.com/43534309/227118784-97d6231d-beb4-4fc9-b760-c47e95817592.png)

and notepad

![notepad-nofocus](https://user-images.githubusercontent.com/43534309/227118824-9d02329f-396d-43b3-aa68-927009a1bd57.png)

We have currently

![beforefix-dashrect](https://user-images.githubusercontent.com/43534309/227119231-19feb2fd-203b-48a2-9e59-62ab63b51ccc.png)


and after fix

![afterfix-nodashrect](https://user-images.githubusercontent.com/43534309/227119263-09be94e2-c6cc-4d7b-9449-a860aabca572.png)

-------------

Commit messages:
 - 4130823: Not painting focus when the radio button has only icon

Changes: https://git.openjdk.org/jdk/pull/13153/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13153&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-4130823
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13153.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13153/head:pull/13153

PR: https://git.openjdk.org/jdk/pull/13153


From liach at openjdk.org  Thu Mar 23 07:15:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 07:15:53 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

src/java.base/share/classes/java/util/Collections.java line 5887:

> 5885:      */
> 5886:     public static  Set newSetFromMap(Map map) {
> 5887:         if (! map.isEmpty())

Suggestion:

        if (!map.isEmpty())

src/java.base/share/classes/java/util/ReverseOrderListView.java line 75:

> 73:      */
> 74:     void checkModifiable() {
> 75:         if (! modifiable)

Suggestion:

        if (!modifiable)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1142805672
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1145708887


From jdv at openjdk.org  Thu Mar 23 07:32:45 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 23 Mar 2023 07:32:45 GMT
Subject: RFR: 6817009: Action.SELECTED_KEY not toggled when using key
 binding
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Jan 2023 10:26:10 GMT, Prasanta Sadhukhan  wrote:

> When the Action.SELECTED_KEY property action is assigned to ToggleButton and an accelerator key binding is mapped to the action, then pressing the accelerator key binding does not toggle the toggle button.
> This is because SwingUtilities.notifyAction does not fire itemStateChanged event for such action related to SELECTED_KEY.
> Fix is to get the Action.SELECTED_KEY command/action and fire itemStateChanged Event via JToggleButton.setSelected() call to notify propertyChange listener of the toggled property.

Apart from jtreg test comment, other changes looks good.
Verified regression test also.

test/jdk/javax/swing/JToggleButton/TestSelectedKey.java line 26:

> 24: /* @test
> 25:    @bug 6817009
> 26:    @summary Verifies if AAction.SELECTED_KEY not toggled when using key binding

This is a headful test, we need to add @headful tag.
Also summary needs to be updated to something like "Verifies that AAction.SELECTED_KEY is not toggled when key binding is used"

-------------

Marked as reviewed by jdv (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12253#pullrequestreview-1353989725
PR Review Comment: https://git.openjdk.org/jdk/pull/12253#discussion_r1145780398


From psadhukhan at openjdk.org  Thu Mar 23 07:41:11 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Mar 2023 07:41:11 GMT
Subject: RFR: 6817009: Action.SELECTED_KEY not toggled when using key
 binding [v2]
In-Reply-To: 
References: 
Message-ID: 

> When the Action.SELECTED_KEY property action is assigned to ToggleButton and an accelerator key binding is mapped to the action, then pressing the accelerator key binding does not toggle the toggle button.
> This is because SwingUtilities.notifyAction does not fire itemStateChanged event for such action related to SELECTED_KEY.
> Fix is to get the Action.SELECTED_KEY command/action and fire itemStateChanged Event via JToggleButton.setSelected() call to notify propertyChange listener of the toggled property.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12253/files
  - new: https://git.openjdk.org/jdk/pull/12253/files/4219c5c7..875d85e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12253&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12253&range=00-01

  Stats: 6 lines in 2 files changed: 1 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12253/head:pull/12253

PR: https://git.openjdk.org/jdk/pull/12253


From psadhukhan at openjdk.org  Thu Mar 23 07:41:11 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Mar 2023 07:41:11 GMT
Subject: RFR: 6817009: Action.SELECTED_KEY not toggled when using key
 binding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Mar 2023 07:28:05 GMT, Jayathirth D V  wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment
>
> test/jdk/javax/swing/JToggleButton/TestSelectedKey.java line 26:
> 
>> 24: /* @test
>> 25:    @bug 6817009
>> 26:    @summary Verifies if AAction.SELECTED_KEY not toggled when using key binding
> 
> This is a headful test, we need to add @headful tag.
> Also summary needs to be updated to something like "Verifies that AAction.SELECTED_KEY is not toggled when key binding is used"

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12253#discussion_r1145786778


From psadhukhan at openjdk.org  Thu Mar 23 07:53:58 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Mar 2023 07:53:58 GMT
Subject: Integrated: 6817009: Action.SELECTED_KEY not toggled when using key
 binding
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Jan 2023 10:26:10 GMT, Prasanta Sadhukhan  wrote:

> When the Action.SELECTED_KEY property action is assigned to ToggleButton and an accelerator key binding is mapped to the action, then pressing the accelerator key binding does not toggle the toggle button.
> This is because SwingUtilities.notifyAction does not fire itemStateChanged event for such action related to SELECTED_KEY.
> Fix is to get the Action.SELECTED_KEY command/action and fire itemStateChanged Event via JToggleButton.setSelected() call to notify propertyChange listener of the toggled property.

This pull request has now been integrated.

Changeset: e2cfcfbf
Author:    Prasanta Sadhukhan 
URL:       https://git.openjdk.org/jdk/commit/e2cfcfbfa90017b1b4ecbf6fb2f0f782c88456a3
Stats:     139 lines in 2 files changed: 139 ins; 0 del; 0 mod

6817009: Action.SELECTED_KEY not toggled when using key binding

Reviewed-by: tr, jdv

-------------

PR: https://git.openjdk.org/jdk/pull/12253


From martin.pernollet at protonmail.com  Thu Mar 23 11:00:09 2023
From: martin.pernollet at protonmail.com (Martin Pernollet)
Date: Thu, 23 Mar 2023 11:00:09 +0000
Subject: JVM hang with Swing and macOS
In-Reply-To: <1C071B5D-9F5C-448E-92E5-7B36F4EC669A@gmail.com>
References: 
 
 
 <1108127A-4940-4240-9853-D44F5A16C28F@cbfiddle.com>
 <7f370680-e1b5-c58a-5e0c-4df79094614a@amazon.com>
 <409A29DA-FB91-42E2-BF1F-16AB4C793D69@gmail.com>
 
 <3Z6cpEUUj9wFPGD38BGfeLvHTD3lnkpOPB8WEcVQDsFZ3-V-a67l9PtQr9-KSQLHA6PtZBbr4tf7ZilUJ1BScR0_OcW6NUFNBVxVnDMhpDE=@protonmail.com>
 <1C071B5D-9F5C-448E-92E5-7B36F4EC669A@gmail.com>
Message-ID: 

> Start another java process -XstartOnMainThread that does the OpenGL part from a Swing application?

Sorry I do not understand your question. If you speak about triggering two process with -XstartOnFirstThread, I think they might both freeze. Or worse, one freeze and the other one get kick/stopped by the former.

I can try this next week because I do not have a macOS with me up to next thursday.

> One hang up there though might be that I don?t think java applications that include the java native commands are allowed in the Mac App Store. Another bug due to each command has it?s own unique CFBundleIdentifier but that identifier is always the same and Apple doesn?t allow duplicates in the App Store.

Being able to deploy on App Store is not an immediate need for me but this is a very interesting point to consider. I'll try to understand how CFBundleIdentifier relates to -XstartOnFIrstThread.

Regards,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mik3hall at gmail.com  Thu Mar 23 11:29:04 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 23 Mar 2023 06:29:04 -0500
Subject: JVM hang with Swing and macOS
In-Reply-To: 
References: 
 
 
 <1108127A-4940-4240-9853-D44F5A16C28F@cbfiddle.com>
 <7f370680-e1b5-c58a-5e0c-4df79094614a@amazon.com>
 <409A29DA-FB91-42E2-BF1F-16AB4C793D69@gmail.com>
 
 <3Z6cpEUUj9wFPGD38BGfeLvHTD3lnkpOPB8WEcVQDsFZ3-V-a67l9PtQr9-KSQLHA6PtZBbr4tf7ZilUJ1BScR0_OcW6NUFNBVxVnDMhpDE=@protonmail.com>
 <1C071B5D-9F5C-448E-92E5-7B36F4EC669A@gmail.com>
 
Message-ID: <46933CF1-B491-4FE9-A059-F3BD3632685A@gmail.com>

Martin

> On Mar 23, 2023, at 6:00 AM, Martin Pernollet  wrote:
> 
> 
> 
>> Start another java process -XstartOnMainThread that does the OpenGL part from a Swing application? 
> 
> Sorry I do not understand your question. If you speak about triggering two process with -XstartOnFirstThread, I think they might both freeze. Or worse, one freeze and the other one get kick/stopped by the former.
> 
> I can try this next week because I do not have a macOS with me up to next thursday.

You launch a Swing application that in turn starts a java command process -XstartOnFirstThread which does your OpenGL, but no Swing. It writes out your image data which the Swing process reads and renders. It sounded like the OpenGL simply produces and Swing consumes. There is not ongoing interaction between the two so they could be fairly easily separated? I haven?t really looked at the code yet so maybe this separation wouldn?t be so easy.

If you think this might be feasible I could be interested in looking at it.

> 
>> One hang up there though might be that I don?t think java applications that include the java native commands are allowed in the Mac App Store. Another bug due to each command has it?s own unique CFBundleIdentifier but that identifier is always the same and Apple doesn?t allow duplicates in the App Store.
> 
> Being able to deploy on App Store is not an immediate need for me but this is a very interesting point to consider. I'll try to understand how CFBundleIdentifier relates to -XstartOnFIrstThread.
> 

This bug came up concerning jpackage applications. The resolution was to not allow jpackage applications that indicate they are going to the Mac App Store to have native java commands. Workarounds might be possible. Maybe at least at this stage you don?t see the code being used in this way. 

If you get to this point workarounds might be possible. 

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bylokhov at amazon.com  Thu Mar 23 16:48:43 2023
From: bylokhov at amazon.com (Sergey Bylokhov)
Date: Thu, 23 Mar 2023 09:48:43 -0700
Subject: JVM hang with Swing and macOS
In-Reply-To: <3Z6cpEUUj9wFPGD38BGfeLvHTD3lnkpOPB8WEcVQDsFZ3-V-a67l9PtQr9-KSQLHA6PtZBbr4tf7ZilUJ1BScR0_OcW6NUFNBVxVnDMhpDE=@protonmail.com>
References: 
 
 <6QaNotL5_WbYMK2V6YyvZYL06NOXFa4SWn10Bq8_Is_InxN5yb5RAhmgNM38JRstYPoECGbrY3wt12zCJkeoP_ab_TerDaew0QrDCy789Jg=@protonmail.com>
 
 
 
 <1108127A-4940-4240-9853-D44F5A16C28F@cbfiddle.com>
 <7f370680-e1b5-c58a-5e0c-4df79094614a@amazon.com>
 <409A29DA-FB91-42E2-BF1F-16AB4C793D69@gmail.com>
 
 <3Z6cpEUUj9wFPGD38BGfeLvHTD3lnkpOPB8WEcVQDsFZ3-V-a67l9PtQr9-KSQLHA6PtZBbr4tf7ZilUJ1BScR0_OcW6NUFNBVxVnDMhpDE=@protonmail.com>
Message-ID: 

On 3/21/23 10:39, Martin Pernollet wrote:
> Hi,
> 
> Thank you Sergey, Michael and Alan.
> 
> It seams the OGLUtilities does not exists anymore 
> . Do 
> you know if there is a replacer?

It is in the shared folder:
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/opengl/OGLUtilities.java

Note that it allows to run the ogl code on a special thread where the java2d use the OGL, and it is 
not an appkit.

-- 
Best regards, Sergey.



From dnguyen at openjdk.org  Thu Mar 23 17:57:14 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 23 Mar 2023 17:57:14 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v8]
In-Reply-To: 
References: 
Message-ID: 

> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
> 
> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
> 
> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
> 
> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Add jtreg scale

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12390/files
  - new: https://git.openjdk.org/jdk/pull/12390/files/fb545c24..4f3707d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12390.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12390/head:pull/12390

PR: https://git.openjdk.org/jdk/pull/12390


From dnguyen at openjdk.org  Thu Mar 23 19:55:39 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 23 Mar 2023 19:55:39 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v9]
In-Reply-To: 
References: 
Message-ID: <7uLi7MOk-F0PIDz9Viqkakgx1BURLX6ppZtht5-jyTo=.215090dc-e857-4066-9e33-24c307705557@github.com>

> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
> 
> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
> 
> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
> 
> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Fix check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12390/files
  - new: https://git.openjdk.org/jdk/pull/12390/files/4f3707d0..ca733984

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12390.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12390/head:pull/12390

PR: https://git.openjdk.org/jdk/pull/12390


From jwaters at openjdk.org  Thu Mar 23 21:57:58 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 23 Mar 2023 21:57:58 GMT
Subject: RFR: 8304718: GetIntArrayElements should not be passed JNI_FALSE
 [v2]
In-Reply-To: <6GasbMg7JNmOkcVZxVB8tax5OM6Qlczo0v1OsiI1YYM=.c0c8054d-b65b-4219-9af0-6214697e96ae@github.com>
References: <6GasbMg7JNmOkcVZxVB8tax5OM6Qlczo0v1OsiI1YYM=.c0c8054d-b65b-4219-9af0-6214697e96ae@github.com>
Message-ID: 

> AWT passes JNI_FALSE to the JVM to avoid a copy, which is not correct since JNI has absolutely no control over whether a copy is made or not. The parameter in question is a pointer to a jboolean that the JVM sets to indicate whether it made a copy or not, which should be passed nullptr because we don't bother about the copy status of the jint

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  awt_Robot.c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13140/files
  - new: https://git.openjdk.org/jdk/pull/13140/files/2c8dd47c..0ce76c20

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13140&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13140&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13140.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13140/head:pull/13140

PR: https://git.openjdk.org/jdk/pull/13140


From jwaters at openjdk.org  Thu Mar 23 22:02:32 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 23 Mar 2023 22:02:32 GMT
Subject: RFR: 8304718: GetIntArrayElements should not be passed JNI_FALSE
 [v3]
In-Reply-To: <6GasbMg7JNmOkcVZxVB8tax5OM6Qlczo0v1OsiI1YYM=.c0c8054d-b65b-4219-9af0-6214697e96ae@github.com>
References: <6GasbMg7JNmOkcVZxVB8tax5OM6Qlczo0v1OsiI1YYM=.c0c8054d-b65b-4219-9af0-6214697e96ae@github.com>
Message-ID: <_FPs0RLAL1K3oef-BOMTaWL_uzhqhAA83VsUwUHf_R0=.869b7752-f171-4a82-a1ed-e23402f4ad86@github.com>

> AWT passes JNI_FALSE to the JVM to avoid a copy, which is not correct since JNI has absolutely no control over whether a copy is made or not. The parameter in question is a pointer to a jboolean that the JVM sets to indicate whether it made a copy or not, which should be passed nullptr because we don't bother about the copy status of the jint

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  LWCToolkit.m

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13140/files
  - new: https://git.openjdk.org/jdk/pull/13140/files/0ce76c20..eb14695c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13140&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13140&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13140.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13140/head:pull/13140

PR: https://git.openjdk.org/jdk/pull/13140


From jwaters at openjdk.org  Thu Mar 23 22:02:34 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 23 Mar 2023 22:02:34 GMT
Subject: RFR: 8304718: GetIntArrayElements should not be passed JNI_FALSE
In-Reply-To: <6GasbMg7JNmOkcVZxVB8tax5OM6Qlczo0v1OsiI1YYM=.c0c8054d-b65b-4219-9af0-6214697e96ae@github.com>
References: <6GasbMg7JNmOkcVZxVB8tax5OM6Qlczo0v1OsiI1YYM=.c0c8054d-b65b-4219-9af0-6214697e96ae@github.com>
Message-ID: <5ihkW2T45c3sWCvg1xzqkfSLZBbLow3JLV0J3hBBZTc=.2a4b9fd2-1ee7-440a-a79b-b484d1530eec@github.com>

On Wed, 22 Mar 2023 14:20:54 GMT, Julian Waters  wrote:

> AWT passes JNI_FALSE to the JVM to avoid a copy, which is not correct since JNI has absolutely no control over whether a copy is made or not. The parameter in question is a pointer to a jboolean that the JVM sets to indicate whether it made a copy or not, which should be passed nullptr because we don't bother about the copy status of the jint

Alright, thanks for the catches Sergey

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13140#issuecomment-1481967106


From serb at openjdk.org  Thu Mar 23 22:49:35 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Mar 2023 22:49:35 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Mar 2023 19:16:17 GMT, Abhishek Kumar  wrote:

>> JAccessWalker was not able to show component tree correctly if we switch pages for HTML content. 
>> 
>> Observation:
>> The issue observed is that the children are not reported correct for root element when switching of pages happened. The reason behind it is that the `getAccessibleChildrenCount` API is called on the old `accessibleContext` object which return the children count as 0. Whenever we switch the page the children count is recalculated based on the root element but the `accessibleContext `object used to retrieve the child remains unchanged and due to that it return the children count 0.
>> 
>> Solution:
>> 
>> Added a condition check to create a new `accessibleContext `object to find out the children count correctly whenever we switch the pages in JEditorPane. 
>> 
>> Checked with the SwingSet2 JEditorPane demo and it reports well the component tree in JAccessWalker.
>> 
>> Steps to verify:
>> 
>> JBS contains the steps to reproduce the scenario.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12707#pullrequestreview-1355770112


From serb at openjdk.org  Thu Mar 23 22:56:22 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Mar 2023 22:56:22 GMT
Subject: RFR: 8301616: Drag & maximize to another monitor places window
 incorrectly (Windows) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Mar 2023 18:59:09 GMT, Nikita Gubarkov  wrote:

>> The `AwtWindow::CheckWindowDPIChange()` hack was introduced for popup windows and breaks maximization logic, so reshape window only if it's not maximized.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301616: Drag & maximize to another monitor places window incorrectly (Windows)

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 374:

> 372:     WINDOWPOS * wp = (WINDOWPOS *)windowPos;
> 373: 
> 374:     // There's no good way to detect partial maximization (e.g. Aero Snap),

Does the bug affect all windows, or only frames/dialog? Can we move this code to the AwtFrame#WmWindowPosChanging?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12367#discussion_r1146954325


From jwaters at openjdk.org  Fri Mar 24 04:12:35 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 24 Mar 2023 04:12:35 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v2]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 22:23:00 GMT, Julian Waters  wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MacOSXPreferencesFile.m

Correct label for awt is client to my knowledge

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13139#issuecomment-1482222230


From duke at openjdk.org  Fri Mar 24 04:37:42 2023
From: duke at openjdk.org (duke)
Date: Fri, 24 Mar 2023 04:37:42 GMT
Subject: Withdrawn: 8299333: Unify exceptions used by all variants of
 ICC_Profile.getInstance(null)
In-Reply-To: 
References: 
Message-ID: 

On Fri, 23 Dec 2022 23:32:45 GMT, Sergey Bylokhov  wrote:

> I tried to clean up the documentation in the `java.awt.color` package and specify how the `null` parameters are handled here and there. But it looks like the `ICC_profile` class is too specific so I would like to discuss it separately.
> 
> The ICC_Profile has these methods:
>  * `getInstance(int)`      - always throws specified `IllegalArgumentException` on the wrong constant
>  * `getInstance(byte[])` - always throws specified `IllegalArgumentException` on `null`
>  * `getInstance(String fileName)` - always throws unspecified `NullPointerException` on `null`
>  * `getInstance(InputStream)`      - thrown unspecified `NullPointerException` before [JDK-8227816](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388) and now throws specified but misleading `IOException: Stream closed` exception on `null`
> 
> So we have 3 methods that can get null as a parameter and each throw a different exception.
> 
> Note that all of the specs for the methods above have this part:
> 
>> @throws IllegalArgumentException If the stream does not contain valid ICC Profile data
> 
> So I have an idea to change `getInstance(String)` and `getInstance(InputStream)` to throw `IllegalArgumentException`  even if I personally prefer NPE to be thrown.
> 
> From another point of view the `ICC_Profile` profile has other methods:
>  * `write(String fileName)` - always throws unspecified `NullPointerException` on `null`
>  * `write(OutputStream) `  - always throws unspecified `NullPointerException` on `null`
> 
> I am not sure we can throw `IllegalArgumentException` from the `write` methods, so the specification for `getInstance(String)` and `getInstance(InputStream)` could be updated to throw NPE on null same as related `write`.
> 
> Thoughts?

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11784


From dholmes at openjdk.org  Fri Mar 24 05:10:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 05:10:30 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v2]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 22:23:00 GMT, Julian Waters  wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MacOSXPreferencesFile.m

Thanks for the correction I thought the mailing list was awt-dev similar to swing-dev.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13139#issuecomment-1482258685


From qamai at openjdk.org  Fri Mar 24 05:37:30 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 24 Mar 2023 05:37:30 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v2]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 22:23:00 GMT, Julian Waters  wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MacOSXPreferencesFile.m

Is this needed? A boolean-to-int conversion returns `1` if the input is `true` and `0` otherwise. The opposite returns `true` for non-zero value and `false` otherwise. Unless we have some tricky `jboolean` value that should not happen they should behave the same?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13139#issuecomment-1482276217


From psadhukhan at openjdk.org  Fri Mar 24 10:43:26 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Mar 2023 10:43:26 GMT
Subject: RFR: 8068824: Exception thrown in JTableHeader after clicking on
 popupmenu opened with right-click on header
Message-ID: 

The issue is observed on mouse right click on the table header to open a pupup menu and then, do a mouse left click on the menu entry in which case we get AIOOBE
This is because the columnIndex for popup menu is returned by `viewIndexForColumn `as -1 seen here https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L745-L753
which is then passed to DefaultTableColumnModel.getColumn(columnIndex) causing it to throw AIOOBE as per the [DefaultTableColumnModel.getColumn spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/table/DefaultTableColumnModel.java#L293)

So, inline with check done for `viewIndexForColumn `
https://github.com/openjdk/jdk/blob/941a7ac7dab243c6033a78880fd31faa803e62ab/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L310-L312
a similar check is added when `viewIndexForColumn `is called

-------------

Commit messages:
 - 8068824: Exception thrown in JTableHeader after clicking on popupmenu opened with right-click on header

Changes: https://git.openjdk.org/jdk/pull/13172/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13172&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8068824
  Stats: 154 lines in 3 files changed: 143 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13172/head:pull/13172

PR: https://git.openjdk.org/jdk/pull/13172


From jwaters at openjdk.org  Fri Mar 24 14:50:33 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 24 Mar 2023 14:50:33 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v2]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
Message-ID: 

On Thu, 23 Mar 2023 22:23:00 GMT, Julian Waters  wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MacOSXPreferencesFile.m

I'd argue it's more for correctness: Indeed it will still compile fine as of now, but the type of jboolean is not the only thing that can change; the other typedef'd boolean type can also be modified later on. Additionally, with compilers getting stricter as newer releases drop, it's a good idea to make sure the signatures match as best as possible, especially between declarations and definitions of the same method

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13139#issuecomment-1482925961


From abhiscxk at openjdk.org  Fri Mar 24 16:20:05 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 24 Mar 2023 16:20:05 GMT
Subject: Integrated: 8273986: JEditorPane HTML Demo - Accessibility issues
In-Reply-To: 
References: 
Message-ID: <0V1gvXOfcryElO9kfmslINOKbbHqGnAwZTPsz2ADjjI=.244406c7-e17a-498a-8462-1c224741ed36@github.com>

On Wed, 22 Feb 2023 05:24:20 GMT, Abhishek Kumar  wrote:

> JAccessWalker was not able to show component tree correctly if we switch pages for HTML content. 
> 
> Observation:
> The issue observed is that the children are not reported correct for root element when switching of pages happened. The reason behind it is that the `getAccessibleChildrenCount` API is called on the old `accessibleContext` object which return the children count as 0. Whenever we switch the page the children count is recalculated based on the root element but the `accessibleContext `object used to retrieve the child remains unchanged and due to that it return the children count 0.
> 
> Solution:
> 
> Added a condition check to create a new `accessibleContext `object to find out the children count correctly whenever we switch the pages in JEditorPane. 
> 
> Checked with the SwingSet2 JEditorPane demo and it reports well the component tree in JAccessWalker.
> 
> Steps to verify:
> 
> JBS contains the steps to reproduce the scenario.

This pull request has now been integrated.

Changeset: 97649489
Author:    Abhishek Kumar 
URL:       https://git.openjdk.org/jdk/commit/97649489d078a3aa34a73e7f686e507f34155788
Stats:     165 lines in 4 files changed: 164 ins; 0 del; 1 mod

8273986: JEditorPane HTML Demo - Accessibility issues

Reviewed-by: kizune, serb

-------------

PR: https://git.openjdk.org/jdk/pull/12707


From tvaleev at openjdk.org  Fri Mar 24 22:28:49 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Fri, 24 Mar 2023 22:28:49 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks  wrote:

> PR for Sequenced Collections implementation.

Hello, Stuart!

I'm really glad that this proposal progresses, and now we have a solid implementation draft. In general, I like it very much. You may find a couple of comments from me in this review, hopefully, they are useful. Sorry if I wrote some nonsense, it's already too late here :-)

src/java.base/share/classes/java/util/LinkedHashMap.java line 782:

> 780:             return svs;
> 781:         } else {
> 782:             return new LinkedValues(false);

Is it possible that this branch is visited? If yes, probably it worth adding a comment when this happens.

src/java.base/share/classes/java/util/LinkedHashMap.java line 1123:

> 1121: 
> 1122:         public V put(K key, V value) {
> 1123:             return base.put(key, value);

Why `put()` simply delegates to `base.put()` while `putAll()` below does more complex containsKey-put-putFirst procedure? I think that `putAll()` should be equivalent to `for(var e : m.entrySet()) put(e.getKey(), e.getValue());`. Am I missing something?

src/java.base/share/classes/java/util/LinkedHashMap.java line 1197:

> 1195: 
> 1196:         public V computeIfAbsent(K key, Function mappingFunction) {
> 1197:             return base.computeIfAbsent(key, mappingFunction);

Again, it's somewhat worrysome that methods like `computeIfAbsent` will actually add new nodes to the end of original LinkedHashMap instead of to the beginning. Probably not very big deal but looks inconsistent...

src/java.base/share/classes/java/util/ReverseOrderDequeView.java line 64:

> 62: 
> 63:     public Spliterator spliterator() {
> 64:         return Spliterators.spliteratorUnknownSize(base.descendingIterator(), 0);

Could we use here `Spliterators.spliterator(this, base.spliterator().characteristics())`? Current implementation is not late-binding and never sized.

src/java.base/share/classes/java/util/ReverseOrderDequeView.java line 103:

> 101:     }
> 102: 
> 103:     // copied from AbstractCollection

Probably not the part of this PR, but it could be reasonable to create some utility CollectionSupport class and create static methods (e.g. `static boolean remove(Collection c, Object o)`) with the implementations of common collection algorithms, like this one. WDYT?

src/java.base/share/classes/java/util/ReverseOrderDequeView.java line 167:

> 165:     public  T[] toArray(T[] a) {
> 166:         // TODO can probably optimize this
> 167:         return toArray(i -> (T[]) java.lang.reflect.Array.newInstance(a.getClass().getComponentType(), i));

Hm... Does it follow the spec when the size of `a` is greater than the size of this collection? In this case, we should return the supplied array filling it partially and setting the next element to null. Here, we will always create a new array, which seems to violate the spec.

src/java.base/share/classes/java/util/ReverseOrderListView.java line 153:

> 151:     public Spliterator spliterator() {
> 152:         // TODO can probably improve this
> 153:         return Spliterators.spliteratorUnknownSize(new DescendingIterator(), 0);

Again, `Spliterators.spliterator(this, base.spliterator().characteristics())` may work better (though haven't checked)

src/java.base/share/classes/java/util/ReverseOrderListView.java line 168:

> 166:         boolean modified = false;
> 167:         for (E e : c) {
> 168:             base.add(0, e);

This is worrysome from performance point of view for base implementations like ArrayList where every insertion means shifting the whole array. At least, we could optimize if `c` is `SequencedCollection`, like `if (c instanceof SequencedCollection sc) base.addAll(0, sc.reversed())`. Otherwise, we can use `base.addAll(0, Arrays.asList(sc.toArray()).reversed())` (with a couple of unchecked casts).

src/java.base/share/classes/java/util/ReverseOrderListView.java line 288:

> 286:     public  T[] toArray(T[] a) {
> 287:         // TODO can probably optimize this
> 288:         return toArray(i -> (T[]) java.lang.reflect.Array.newInstance(a.getClass().getComponentType(), i));

Incorrect implementation again

src/java.base/share/classes/java/util/ReverseOrderListView.java line 316:

> 314:     public void add(int index, E element) {
> 315:         checkModifiable();
> 316:         base.add(base.size() - index, element);

Note that if index is out of bounds, the original collection may throw a confusing exception, as `base.size() - index` will be reported instead. Probably adding explicit bounds checking call before delegation would be better. Same applies to other index-based operations.

src/java.base/share/classes/java/util/ReverseOrderListView.java line 319:

> 317:     }
> 318: 
> 319:     public boolean addAll(int index, Collection c) {

Similar considerations, as for `addAll(Collection)`.

src/java.base/share/classes/java/util/ReverseOrderSortedMapView.java line 99:

> 97: 
> 98:     public Set keySet() {
> 99:         return new AbstractSet<>() {

At very least, please delegate `contains`, `remove`, and `clear`, to avoid O(N) complexity there. Same for `values()` and `entrySet()`

src/java.base/share/classes/java/util/ReverseOrderSortedMapView.java line 185:

> 183: 
> 184:     static  Iterator descendingKeyIterator(SortedMap map) {
> 185:         return new Iterator<>() {

Probably create `descendingEntryIterator` as base, and derive `descendingKeyIterator` and `descendingValueIterator`? This way, `map.get()` inside `descendingValueIterator` and `descendingEntryIterator` could be avoided.

-------------

PR Review: https://git.openjdk.org/jdk/pull/7387#pullrequestreview-1357459425
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148075441
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148079423
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148081322
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148090986
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148092195
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148096483
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148097411
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148098823
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148099182
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148099726
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148100155
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148102202
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148103978


From tvaleev at openjdk.org  Fri Mar 24 22:28:50 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Fri, 24 Mar 2023 22:28:50 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <9_34ZKelWdc1dC_aPGVB9zo4caFdMa2xPmnjlzd94CY=.491ae57b-b117-4372-a71f-4669e2fd3545@github.com>
 
Message-ID: 

On Thu, 3 Nov 2022 00:49:52 GMT, Stuart Marks  wrote:

>> @stuart-marks What are examples of cases where it wouldn't be reasonable: https://github.com/openjdk/jdk/pull/7387/files#diff-2b261a88d9ed30893d24186a36ef500d284d82e8f345591fc6c44ed5ae15da4fR161 ?
>
> I had to uncomment that line to figure out what broke. :-) Turns out `TreeSet.reversed().reversed()` doesn't return the original TreeSet. This is because `descendingSet().descendingSet()` doesn't unwrap, and neither does TreeMap's `descendingMap().descendingMap()`. I don't know what this wasn't done in the first place. Nonetheless, since unwrapping isn't done in the underlying implementation, it doesn't seem reasonable for the specification to require it be done. Furthermore this enables `reversed()` to be implemented as a default method that simply delegates to the respective `descending*()` method.

Also, `unmodifiableSequencedCollection(c).reversed().reversed()` does not return the original `unmodifiableSequencedCollection(c)`. And we probably cannot even specify that `x.reversed().reversed().equals(x)`, due to lack of `equals()` specification for all collections (in particular, Deques)...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148106570


From smarks at openjdk.org  Sat Mar 25 03:19:38 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 25 Mar 2023 03:19:38 GMT
Subject: RFR: 8266571: Sequenced Collections
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Fri, 24 Mar 2023 22:26:03 GMT, Tagir F. Valeev  wrote:

>> PR for Sequenced Collections implementation.
>
> Hello, Stuart!
> 
> I'm really glad that this proposal progresses, and now we have a solid implementation draft. In general, I like it very much. You may find a couple of comments from me in this review, hopefully, they are useful. Sorry if I wrote some nonsense, it's already too late here :-)

@amaembo 

> I'm really glad that this proposal progresses, and now we have a solid implementation draft. In general, I like it very much. You may find a couple of comments from me in this review, hopefully, they are useful. Sorry if I wrote some nonsense, it's already too late here :-)

Thanks for looking! I took a quick look through the comments and they seem reasonable. Right now I'm concentrating on the specification in order to get the CSR Finalized. Do you have any comments on the specifications? I'll take a look at the implementation comments afterward. Some I'll be able to address before integration, but some I might need to postpone until later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1483701691


From smarks at openjdk.org  Sat Mar 25 03:54:23 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Sat, 25 Mar 2023 03:54:23 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

> PR for Sequenced Collections implementation.

Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:

 - More specification tweaks.
 - Add simple overrides to ArrayList.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7387/files
  - new: https://git.openjdk.org/jdk/pull/7387/files/31f7d102..500841de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=00-01

  Stats: 155 lines in 10 files changed: 110 ins; 13 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387


From forax at openjdk.org  Sat Mar 25 07:13:38 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 25 Mar 2023 07:13:38 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: <3e6DVS8g_L4Yv27PiLlRyv6Fu7RsSR43gvKKHZKQvmw=.296a96fe-6134-407b-8078-d65e54bfbc30@github.com>

On Sat, 25 Mar 2023 03:54:23 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - More specification tweaks.
>  - Add simple overrides to ArrayList.

src/java.base/share/classes/java/util/ArrayList.java line 573:

> 571:         } else {
> 572:             Object[] es = elementData;
> 573:             sz--;

This line and the following two lines can be understood as the field size being updated which is not the case.
I think it's more readable to use

@SuppressWarnings("unchecked") E oldValue = (E) es[sz - 1];
fastRemove(es, sz - 1);

The JIT will common the subexpression 'sz - 1' at runtime.

src/java.base/share/classes/java/util/Collections.java line 1173:

> 1171:      * @serial include
> 1172:      */
> 1173:     static class UnmodifiableSequencedCollection extends UnmodifiableCollection

`private` is missing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148319735
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148319899


From forax at openjdk.org  Sat Mar 25 07:22:40 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 25 Mar 2023 07:22:40 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Sat, 25 Mar 2023 03:54:23 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - More specification tweaks.
>  - Add simple overrides to ArrayList.

src/java.base/share/classes/java/util/Collections.java line 1184:

> 1182: 
> 1183:         @SuppressWarnings("unchecked")
> 1184:         private SequencedCollection rc() {

I suggest to use 'delegate' as name instead of 'rc' (no idea what 'rc' means)

src/java.base/share/classes/java/util/Collections.java line 6014:

> 6012:      */
> 6013:     public static  SequencedSet newSequencedSetFromMap(SequencedMap map) {
> 6014:         if (! map.isEmpty())

This line does an implicit NPE check, either make it explicit using requireNonNull or at least add a comment

src/java.base/share/classes/java/util/Collections.java line 6023:

> 6021:      */
> 6022:     private static class SequencedSetFromMap extends SetFromMap implements SequencedSet {
> 6023:         private final E nsee(Map.Entry e) {

`static` instead of `final`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148320373
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148320720
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148320942


From forax at openjdk.org  Sat Mar 25 07:43:47 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 25 Mar 2023 07:43:47 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Sat, 25 Mar 2023 03:54:23 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - More specification tweaks.
>  - Add simple overrides to ArrayList.

src/java.base/share/classes/java/util/LinkedHashSet.java line 297:

> 295:      */
> 296:     public SequencedSet reversed() {
> 297:         class ReverseLinkedHashSetView extends AbstractSet implements SequencedSet {

This class should be declared `static` (and private) which means it should not be declared inside reversed.

src/java.base/share/classes/java/util/LinkedHashSet.java line 313:

> 311:                 boolean present = LinkedHashSet.this.contains(e);
> 312:                 LinkedHashSet.this.addFirst(e);
> 313:                 return ! present;

why there is a space between '!' and 'present' given that you have removed this space in another change above ?

src/java.base/share/classes/java/util/LinkedList.java line 1293:

> 1291:     @SuppressWarnings("serial")
> 1292:     static class ReverseOrderLinkedListView extends LinkedList implements java.io.Externalizable {
> 1293:         final LinkedList list;

Using 3 different fields feel ugly given it seems you only need one.
Why do you not use the casting strategy you are using for the other views ?

src/java.base/share/classes/java/util/List.java line 802:

> 800:      */
> 801:     default E getFirst() {
> 802:         if (this.isEmpty())

weirdly, sometimes you use braces around the ''if and sometimes you don't ?

src/java.base/share/classes/java/util/ReverseOrderListView.java line 60:

> 58:     }
> 59: 
> 60:     ReverseOrderListView(List list, boolean modifiable) {

should be 'private' to force users to use 'of'

src/java.base/share/classes/java/util/ReverseOrderListView.java line 191:

> 189:         if (o == this)
> 190:             return true;
> 191:         if (!(o instanceof List))

should be `if (!(o instanceof List list))`

src/java.base/share/classes/java/util/ReverseOrderListView.java line 209:

> 207:         int hashCode = 1;
> 208:         for (E e : this)
> 209:             hashCode = 31*hashCode + (e==null ? 0 : e.hashCode());

`31 * hashCode` instead of `31*hashCode`

src/java.base/share/classes/java/util/ReverseOrderSortedMapView.java line 44:

> 42:     public static  SortedMap of(SortedMap map) {
> 43:         if (map instanceof ReverseOrderSortedMapView) {
> 44:             return ((ReverseOrderSortedMapView)map).base;

use `map instanceof ReverseOrderSortedMapView view` instead to remove the ugly cast below

src/java.base/share/classes/java/util/ReverseOrderSortedMapView.java line 215:

> 213:     static  Iterator descendingValueIterator(SortedMap map) {
> 214:         return new Iterator<>() {
> 215:             Iterator keyIterator = descendingKeyIterator(map);

`private final` or better declare it above as a local variable and capture it inside the anonymous class

src/java.base/share/classes/java/util/ReverseOrderSortedMapView.java line 329:

> 327:                 K prevKey = null;
> 328:                 boolean dead = false;
> 329:                 Iterator> it = descendingEntryIterator(base);

see above about declare it as a local variable, all other fields should be `private`

src/java.base/share/classes/java/util/ReverseOrderSortedSetView.java line 61:

> 59:             return true;
> 60: 
> 61:         if (!(o instanceof Set))

use `if (!(o instanceof Set set))` to avoid the cast below

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148321554
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148321635
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148321852
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148322049
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148322292
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148322490
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148322511
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148322728
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148322895
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148323316
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1148323602


From forax at openjdk.org  Sat Mar 25 08:22:41 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 25 Mar 2023 08:22:41 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>

On Sat, 25 Mar 2023 03:54:23 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - More specification tweaks.
>  - Add simple overrides to ArrayList.

This change is absolutely massive, implementing reversed() basically doubles the number of implementations which means multiple years of debugging / spec fixing.

Reversing a List makes sense, reversing a LinkedHashSet/LinkedHashMap is a nice to have. Having the concept of first and last (getFirst()/getLast()/etc) on Collection is something long awaited. 

I understand that wanting to separate the concept of Collection and SequencedCollection can be conceptually nice, but 
multiplying the number of interfaces also multiplies the number of implementations. Pragmatically, this patch is too big compared to how useful it is.

I get that Oracle is rich, but this JEP is not only a burden for Oracle but for the whole community.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1483761783


From markus at headcrashing.eu  Sat Mar 25 17:58:39 2023
From: markus at headcrashing.eu (Markus Karg)
Date: Sat, 25 Mar 2023 18:58:39 +0100
Subject: Proposal: 8302281 - ImageReader and ImageWrite should implement
 Closable
Message-ID: <000301d95f43$6e340210$4a9c0630$@eu>

I like to propose a small addition to ImageReader and ImageWrite, as it
makes using them a bit simpler and safer: ImageReader and ImageWriter should
implement the Closable interface
(https://bugs.openjdk.org/browse/JDK-8302281).

 

The reason for this proposal is that I noticed that people tend to not
dispose these instances using dispose(), because they simply did not
understand that they have to. People these days are used to just try out
try-with-resources and if the IDE complains that this is not supported, then
they (falsely and carelessly) assume that there is no need to dispose these
instances. Only few people actively check the Javadocs if there is any other
method besides close(), like in this case: dispose(). For those people it
would be convenient and safe if we implement Closable. Also, such a change
would allow to write safe code little a bit simpler. The change is backwards
compatible and does not imply big risk or effort, and I do not see a
relevant reason why we should abstain from this addition, but maybe I am
missing something?

 

Hence I kindly ask for constructive comments on this idea.

 

I have already opened a draft on Github to outline what I have in mind:
https://github.com/openjdk/jdk/pull/12098

 

With kinds regards

-Markus Karg

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From serb at openjdk.org  Mon Mar 27 05:09:31 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Mar 2023 05:09:31 GMT
Subject: RFR: 8304718: GetIntArrayElements should not be passed JNI_FALSE
 [v3]
In-Reply-To: <_FPs0RLAL1K3oef-BOMTaWL_uzhqhAA83VsUwUHf_R0=.869b7752-f171-4a82-a1ed-e23402f4ad86@github.com>
References: <6GasbMg7JNmOkcVZxVB8tax5OM6Qlczo0v1OsiI1YYM=.c0c8054d-b65b-4219-9af0-6214697e96ae@github.com>
 <_FPs0RLAL1K3oef-BOMTaWL_uzhqhAA83VsUwUHf_R0=.869b7752-f171-4a82-a1ed-e23402f4ad86@github.com>
Message-ID: 

On Thu, 23 Mar 2023 22:02:32 GMT, Julian Waters  wrote:

>> AWT passes JNI_FALSE to the JVM to avoid a copy, which is not correct since JNI has absolutely no control over whether a copy is made or not. The parameter in question is a pointer to a jboolean that the JVM sets to indicate whether it made a copy or not, which should be passed nullptr because we don't bother about the copy status of the jint
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   LWCToolkit.m

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13140#pullrequestreview-1358332444


From serb at openjdk.org  Mon Mar 27 05:13:31 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Mar 2023 05:13:31 GMT
Subject: RFR: 8304501: Remove orphaned demo netbeans projects [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Mar 2023 11:24:12 GMT, Eirik Bjorsnos  wrote:

>> Please review this PR which suggests we remove the orhphaned `SwingApplet` netbeans project directory.
>> 
>> The `SwingApplet` demo was removed in [JDK-8205119](https://bugs.openjdk.org/browse/JDK-8205119), but the netbeans projects files were left behind.
>> 
>> Additionally, the following netbeans projects reference source files that do not exist (if they ever did?):
>> 
>> - src/demo/share/nbproject/management/FullThreadDump
>> - src/demo/share/nbproject/management/JTop
>> - src/demo/share/nbproject/management/MemoryMonitor
>> - src/demo/share/nbproject/management/VerboseGC
>> - src/demo/share/nbproject/scripting/jconsole-plugin
>> 
>> The PR deletes files in these directories as well.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete netbeans project files in src/demo/share/nbproject/management and src/demo/share/nbproject/scripting

Marked as reviewed by serb (Reviewer).

Deleting the SwingApplet looks fine.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13098#pullrequestreview-1358336160
PR Comment: https://git.openjdk.org/jdk/pull/13098#issuecomment-1484505781


From duke at openjdk.org  Mon Mar 27 05:51:38 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 27 Mar 2023 05:51:38 GMT
Subject: RFR: 8304501: Remove orphaned demo netbeans projects [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 27 Mar 2023 05:10:52 GMT, Sergey Bylokhov  wrote:

> Deleting the SwingApplet looks fine.

This PR also deletes five other projects in `management` and `scripting`. Are those also okay?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13098#issuecomment-1484532730


From azvegint at openjdk.org  Mon Mar 27 07:38:35 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 27 Mar 2023 07:38:35 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 17 Mar 2023 18:35:07 GMT, Damon Nguyen  wrote:

>> The issue is in Aqua L&F when an editable JComboBox with a border is used. In this case, when the comboBox is clicked for the drop-down menu to show, the drop-down menu appears at the wrong coordinates (blocking the text of the comboBox and making it unreadable).
>> 
>> This seems to have been the case for a while and a similar issue appeared recently where an editable Aqua JComboBox also had wrong positioning due to having a border.
>> 
>> This fix checks for a border and modifies the bounds to accommodate the border's size. Then the usual calculations for the comboBox popup works as expected.
>> 
>> The new headful test creates an editable comboBox with a TitledBorder and with no border. Then, it automatically clicks the comboBox to open the popup, and clicks where the position of the first selectionItem should be. Finally, it checks if the selected item is correct. This is for all L&F's and the test passes on all OS's.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Mac test to match native

test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 78:

> 76:                     String[] comboStrings = {"One", "Two", "Three"};
> 77: 
> 78:                     cb1 = new JComboBox(comboStrings);

Could you please use diamond operator here and after on JComboBox to avoid warnings?

test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 146:

> 144:                 checkSelection(cb1Str, cb2Str, cb3Str, cb4Str);
> 145:             } finally {
> 146:                 SwingUtilities.invokeAndWait(() -> frame.dispose());

With null check it will be more robust.

test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 194:

> 192:         } else {
> 193:             robot.mouseMove(p.x + width - BUTTON_OFFSET,
> 194:                     p.y + (height / 2) + POPUP_OFFSET);

I am having a solid 10 sec delay with Motif LaF for forth ComboBox.
We are moving mouse really close to the bottom right corner, so resize mouse cursor appears `?`.
This somehow triggers [JDK-8299937](https://bugs.openjdk.org/browse/JDK-8299937)  behavior.

Without adding `POPUP_OFFSET` all works fine(tested on Mac and Ubuntu).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12750#discussion_r1148840265
PR Review Comment: https://git.openjdk.org/jdk/pull/12750#discussion_r1148842212
PR Review Comment: https://git.openjdk.org/jdk/pull/12750#discussion_r1148861930


From psadhukhan at openjdk.org  Mon Mar 27 10:21:49 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 27 Mar 2023 10:21:49 GMT
Subject: Integrated: 7169951: SwingSet2 throws NullPointerException with Nimbus
 L&F
In-Reply-To: 
References: 
Message-ID: <4Ta0GRQxGfq68XRgfp0dnFhJwhplix9JVkgRRHEfJHc=.9e87ad2f-43c0-4542-972e-fd51ae8a1e9d@github.com>

On Fri, 13 Jan 2023 04:25:59 GMT, Prasanta Sadhukhan  wrote:

> It is observed that if SwingSet2 is run in Nimbus L&F and
> we drag the icon tool bar (which is floatable) out of the GUI Window
> and  Once the tool bar is detached, click on "Look & Feel" menu option to change to any L&F (say Java L&F)
> it causes NPE due to font being null when getFontMetrics() is called
> 
> In other L&F, it uses the tabPane's [font ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L2177) whereas in Nimbus font is obtained from getStyle().getFont() which returns null when toolbar is detached from the main window.
> The proposed fix is to get tabPane's font if the font passed is null alike other L&Fs. 
> 
> No regression test is made as it can be verified with SwingSet2..

This pull request has now been integrated.

Changeset: 0712adc2
Author:    Prasanta Sadhukhan 
URL:       https://git.openjdk.org/jdk/commit/0712adc2dd2e61f9409dd5fd210bc6a8c5b8276d
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

7169951: SwingSet2 throws NullPointerException with Nimbus L&F

Reviewed-by: abhiscxk, jdv

-------------

PR: https://git.openjdk.org/jdk/pull/11984


From jwaters at openjdk.org  Mon Mar 27 15:16:01 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 27 Mar 2023 15:16:01 GMT
Subject: Integrated: 8304718: GetIntArrayElements should not be passed
 JNI_FALSE
In-Reply-To: <6GasbMg7JNmOkcVZxVB8tax5OM6Qlczo0v1OsiI1YYM=.c0c8054d-b65b-4219-9af0-6214697e96ae@github.com>
References: <6GasbMg7JNmOkcVZxVB8tax5OM6Qlczo0v1OsiI1YYM=.c0c8054d-b65b-4219-9af0-6214697e96ae@github.com>
Message-ID: 

On Wed, 22 Mar 2023 14:20:54 GMT, Julian Waters  wrote:

> AWT passes JNI_FALSE to the JVM to avoid a copy, which is not correct since JNI has absolutely no control over whether a copy is made or not. The parameter in question is a pointer to a jboolean that the JVM sets to indicate whether it made a copy or not, which should be passed nullptr because we don't bother about the copy status of the jint

This pull request has now been integrated.

Changeset: 6b2f34f8
Author:    Julian Waters 
URL:       https://git.openjdk.org/jdk/commit/6b2f34f88a39031d17b858ffcf631b2fd101c2eb
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8304718: GetIntArrayElements should not be passed JNI_FALSE

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/13140


From dnguyen at openjdk.org  Mon Mar 27 16:29:02 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 27 Mar 2023 16:29:02 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v7]
In-Reply-To: 
References: 
Message-ID: 

> The issue is in Aqua L&F when an editable JComboBox with a border is used. In this case, when the comboBox is clicked for the drop-down menu to show, the drop-down menu appears at the wrong coordinates (blocking the text of the comboBox and making it unreadable).
> 
> This seems to have been the case for a while and a similar issue appeared recently where an editable Aqua JComboBox also had wrong positioning due to having a border.
> 
> This fix checks for a border and modifies the bounds to accommodate the border's size. Then the usual calculations for the comboBox popup works as expected.
> 
> The new headful test creates an editable comboBox with a TitledBorder and with no border. Then, it automatically clicks the comboBox to open the popup, and clicks where the position of the first selectionItem should be. Finally, it checks if the selected item is correct. This is for all L&F's and the test passes on all OS's.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Add null check and diamond op. Remove offset.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12750/files
  - new: https://git.openjdk.org/jdk/pull/12750/files/76bac3a7..4e704cfb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12750&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12750&range=05-06

  Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12750.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12750/head:pull/12750

PR: https://git.openjdk.org/jdk/pull/12750


From dnguyen at openjdk.org  Mon Mar 27 16:33:16 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 27 Mar 2023 16:33:16 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 27 Mar 2023 06:33:11 GMT, Alexander Zvegintsev  wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Mac test to match native
>
> test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 78:
> 
>> 76:                     String[] comboStrings = {"One", "Two", "Three"};
>> 77: 
>> 78:                     cb1 = new JComboBox(comboStrings);
> 
> Could you please use diamond operator here and after on JComboBox to avoid warnings?

I didn't see this warning myself but I added the operator on the comboboxes.

> test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 146:
> 
>> 144:                 checkSelection(cb1Str, cb2Str, cb3Str, cb4Str);
>> 145:             } finally {
>> 146:                 SwingUtilities.invokeAndWait(() -> frame.dispose());
> 
> With null check it will be more robust.

Added

> test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 194:
> 
>> 192:         } else {
>> 193:             robot.mouseMove(p.x + width - BUTTON_OFFSET,
>> 194:                     p.y + (height / 2) + POPUP_OFFSET);
> 
> I am having a solid 10 sec delay with Motif LaF for forth ComboBox.
> We are moving mouse really close to the bottom right corner, so resize mouse cursor appears `?`.
> This somehow triggers [JDK-8299937](https://bugs.openjdk.org/browse/JDK-8299937)  behavior.
> 
> Without adding `POPUP_OFFSET` all works fine(tested on Mac and Ubuntu).

Removed the offset for the button click

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12750#discussion_r1149505172
PR Review Comment: https://git.openjdk.org/jdk/pull/12750#discussion_r1149505292
PR Review Comment: https://git.openjdk.org/jdk/pull/12750#discussion_r1149505624


From dnguyen at openjdk.org  Mon Mar 27 17:07:57 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 27 Mar 2023 17:07:57 GMT
Subject: Integrated: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color
In-Reply-To: 
References: 
Message-ID: <5pUrKvW1SjpJQzldaRlqCJNek6nvU4N4LhJyXlhi6_M=.ea06e002-3d98-4998-b3f2-667a4f1230e5@github.com>

On Thu, 2 Feb 2023 16:33:06 GMT, Damon Nguyen  wrote:

> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
> 
> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
> 
> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
> 
> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.

This pull request has now been integrated.

Changeset: 87b314a9
Author:    Damon Nguyen 
Committer: Alexander Zuev 
URL:       https://git.openjdk.org/jdk/commit/87b314a985c5c3937c1d1d8daadd3e9f8b1acd9d
Stats:     238 lines in 3 files changed: 229 ins; 6 del; 3 mod

7093691: Nimbus LAF: disabled JComboBox using renderer has bad font color

Reviewed-by: honkar, kizune, psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/12390


From dnguyen at openjdk.org  Mon Mar 27 17:12:51 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 27 Mar 2023 17:12:51 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v8]
In-Reply-To: 
References: 
Message-ID: 

> The issue is in Aqua L&F when an editable JComboBox with a border is used. In this case, when the comboBox is clicked for the drop-down menu to show, the drop-down menu appears at the wrong coordinates (blocking the text of the comboBox and making it unreadable).
> 
> This seems to have been the case for a while and a similar issue appeared recently where an editable Aqua JComboBox also had wrong positioning due to having a border.
> 
> This fix checks for a border and modifies the bounds to accommodate the border's size. Then the usual calculations for the comboBox popup works as expected.
> 
> The new headful test creates an editable comboBox with a TitledBorder and with no border. Then, it automatically clicks the comboBox to open the popup, and clicks where the position of the first selectionItem should be. Finally, it checks if the selected item is correct. This is for all L&F's and the test passes on all OS's.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Add null check for frame

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12750/files
  - new: https://git.openjdk.org/jdk/pull/12750/files/4e704cfb..07f11f63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12750&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12750&range=06-07

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12750.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12750/head:pull/12750

PR: https://git.openjdk.org/jdk/pull/12750


From azvegint at openjdk.org  Mon Mar 27 17:28:44 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 27 Mar 2023 17:28:44 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Mar 2023 17:12:51 GMT, Damon Nguyen  wrote:

>> The issue is in Aqua L&F when an editable JComboBox with a border is used. In this case, when the comboBox is clicked for the drop-down menu to show, the drop-down menu appears at the wrong coordinates (blocking the text of the comboBox and making it unreadable).
>> 
>> This seems to have been the case for a while and a similar issue appeared recently where an editable Aqua JComboBox also had wrong positioning due to having a border.
>> 
>> This fix checks for a border and modifies the bounds to accommodate the border's size. Then the usual calculations for the comboBox popup works as expected.
>> 
>> The new headful test creates an editable comboBox with a TitledBorder and with no border. Then, it automatically clicks the comboBox to open the popup, and clicks where the position of the first selectionItem should be. Finally, it checks if the selected item is correct. This is for all L&F's and the test passes on all OS's.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add null check for frame

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12750#pullrequestreview-1359552321


From dnguyen at openjdk.org  Mon Mar 27 19:07:48 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 27 Mar 2023 19:07:48 GMT
Subject: Integrated: 8302558: Editable JComboBox's popup blocks user from
 seeing characters in Aqua look and feel
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Feb 2023 21:54:30 GMT, Damon Nguyen  wrote:

> The issue is in Aqua L&F when an editable JComboBox with a border is used. In this case, when the comboBox is clicked for the drop-down menu to show, the drop-down menu appears at the wrong coordinates (blocking the text of the comboBox and making it unreadable).
> 
> This seems to have been the case for a while and a similar issue appeared recently where an editable Aqua JComboBox also had wrong positioning due to having a border.
> 
> This fix checks for a border and modifies the bounds to accommodate the border's size. Then the usual calculations for the comboBox popup works as expected.
> 
> The new headful test creates an editable comboBox with a TitledBorder and with no border. Then, it automatically clicks the comboBox to open the popup, and clicks where the position of the first selectionItem should be. Finally, it checks if the selected item is correct. This is for all L&F's and the test passes on all OS's.

This pull request has now been integrated.

Changeset: 80e2d52f
Author:    Damon Nguyen 
Committer: Alexander Zvegintsev 
URL:       https://git.openjdk.org/jdk/commit/80e2d52f76806bc886138a0fd4c34b1ca3dc4c0b
Stats:     227 lines in 2 files changed: 225 ins; 0 del; 2 mod

8302558: Editable JComboBox's popup blocks user from seeing characters in Aqua look and feel

Reviewed-by: psadhukhan, azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/12750


From duke at openjdk.org  Mon Mar 27 21:52:16 2023
From: duke at openjdk.org (Jeremy)
Date: Mon, 27 Mar 2023 21:52:16 GMT
Subject: RFR: 8303904: Transparent Windows Paint Wrong (Opaque) w/o Volatile
 Buffering
Message-ID: 

The original write-up contains two complaints:
1. The window is opaque, so pixels that should be transparent are black.
2. The window is the wrong resolution. On a 200% resolution monitor it renders as if it were 100% (so it looks pixelated).

I recommend splitting this up into separate tickets.

This PR addresses the first (probably most offensive) issue: the window is now transparent.

I experimented with a change that resolves the second issue (image resolution) here:
https://github.com/openjdk/jdk/commit/90735b7c01c66268776998c1b6aedc3250427002

... that works, but IMO that looks riskier and should be part of a separate discussion.

I only have a Mac configured right now to test against, so I've confirmed the MTLGraphicsConfig and CGLGraphicsConfig changes. The other GraphicsConfig changes are identical, but I haven't confirmed that this new test passes in those environments. (I did confirm that those GraphicsConfig files appear to support getColorModel(Transparency.TRANSLUCENT), so I'm optimistic they'll be OK.

-------------

Commit messages:
 - 8303904: fixing compiler `cannot find symbol` errors
 - 8303904: cleaning up comment
 - 8303904: apply same solution to other GraphicsConfigurations
 - 8303904: resolve failing bug8308904_OGL test on Mac
 - 8303904: adding failing unit test for OpenGL on Mac
 - 8303904: updating instruction text to reflect narrowed focus of this branch
 - 8303904: rolling back prev createAcceleratedImage commit
 - 8303904: change createAcceleratedImage to return a potentially high-res image
 - 8303904: use Transparency.TRANSLUCENT for non-opaque windows
 - 8303904: Add failing unit test
 - ... and 4 more: https://git.openjdk.org/jdk/compare/98a7a60f...4284d4cd

Changes: https://git.openjdk.org/jdk/pull/13196/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13196&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303904
  Stats: 225 lines in 7 files changed: 220 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13196.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13196/head:pull/13196

PR: https://git.openjdk.org/jdk/pull/13196


From smarks at openjdk.org  Tue Mar 28 00:01:50 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 28 Mar 2023 00:01:50 GMT
Subject: RFR: 8266571: Sequenced Collections [v3]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: 

> PR for Sequenced Collections implementation.

Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:

 - Merge branch 'master' into JDK-8266571-SequencedCollections
 - Update copyrights.
 - More specification tweaks.
 - Add simple overrides to ArrayList.
 - Specification cleanups.
 - Update spec of CopyOnWriteArrayList::reversed.
 - Move AbstractViewCollection to AbstractMap.ViewCollection to avoid exposing it publicly.
 - Merge branch 'master' into JDK-8266571-SequencedCollections
   Resolve conflict by deleting IdentityLinkedList.java
 - Merge branch 'master' into JDK-8266571-SequencedCollections
 - Fix indentation.
 - ... and 68 more: https://git.openjdk.org/jdk/compare/6aec6f3a...91c4eabe

-------------

Changes: https://git.openjdk.org/jdk/pull/7387/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=02
  Stats: 6647 lines in 39 files changed: 6509 ins; 11 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387


From smarks at openjdk.org  Tue Mar 28 00:04:46 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 28 Mar 2023 00:04:46 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
Message-ID: 

On Sat, 25 Mar 2023 08:19:18 GMT, R?mi Forax  wrote:

>> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>
> This change is absolutely massive, implementing reversed() basically doubles the number of implementations which means multiple years of debugging / spec fixing.
> 
> Reversing a List makes sense, reversing a LinkedHashSet/LinkedHashMap is a nice to have. Having the concept of first and last (getFirst()/getLast()/etc) on Collection is something long awaited. 
> 
> I understand that wanting to separate the concept of Collection and SequencedCollection can be conceptually nice, but 
> multiplying the number of interfaces also multiplies the number of implementations. Pragmatically, this patch is too big compared to how useful it is.
> 
> I get that Oracle is rich, but this JEP is not only a burden for Oracle but for the whole community.

@forax 

Funnily, I was thinking the other day that this change is quite small given that I've been working on it for over two years. :-)

Anyway, thanks for looking through the implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1486016843


From smarks at openjdk.org  Tue Mar 28 01:14:01 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 28 Mar 2023 01:14:01 GMT
Subject: RFR: 8266571: Sequenced Collections [v3]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Fri, 24 Mar 2023 21:28:18 GMT, Tagir F. Valeev  wrote:

>> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:
>> 
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>  - Update copyrights.
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>>  - Specification cleanups.
>>  - Update spec of CopyOnWriteArrayList::reversed.
>>  - Move AbstractViewCollection to AbstractMap.ViewCollection to avoid exposing it publicly.
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>    Resolve conflict by deleting IdentityLinkedList.java
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>  - Fix indentation.
>>  - ... and 68 more: https://git.openjdk.org/jdk/compare/6aec6f3a...91c4eabe
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 782:
> 
>> 780:             return svs;
>> 781:         } else {
>> 782:             return new LinkedValues(false);
> 
> Is it possible that this branch is visited? If yes, probably it worth adding a comment when this happens.

Good point! This was a vestige of an earlier incarnation where a values() view from a subclass could be stored in the `values` field, and of course it would not be a SequencedCollection; thus a new one would have to be created in order to satisfy this method's requirements. However, because the `values` field is a cache that is only set here, we can rely on it to be sequenced. So I've simplified this to assume that the downcast will be successful.

This highlights the fact that a subclass that overrides values() to create and return its own view collection will potentially have different semantics from the view returned by sequencedValues(). For example, they might return different mappings. Unfortunately I think this is unavoidable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1149926145


From smarks at openjdk.org  Tue Mar 28 01:31:45 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 28 Mar 2023 01:31:45 GMT
Subject: RFR: 8266571: Sequenced Collections [v3]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Fri, 24 Mar 2023 21:35:22 GMT, Tagir F. Valeev  wrote:

>> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:
>> 
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>  - Update copyrights.
>>  - More specification tweaks.
>>  - Add simple overrides to ArrayList.
>>  - Specification cleanups.
>>  - Update spec of CopyOnWriteArrayList::reversed.
>>  - Move AbstractViewCollection to AbstractMap.ViewCollection to avoid exposing it publicly.
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>    Resolve conflict by deleting IdentityLinkedList.java
>>  - Merge branch 'master' into JDK-8266571-SequencedCollections
>>  - Fix indentation.
>>  - ... and 68 more: https://git.openjdk.org/jdk/compare/6aec6f3a...91c4eabe
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 1123:
> 
>> 1121: 
>> 1122:         public V put(K key, V value) {
>> 1123:             return base.put(key, value);
> 
> Why `put()` simply delegates to `base.put()` while `putAll()` below does more complex containsKey-put-putFirst procedure? I think that `putAll()` should be equivalent to `for(var e : m.entrySet()) put(e.getKey(), e.getValue());`. Am I missing something?

I think you're right, you're not missing anything. The entry that is put() should always go at the end of this view, and since this is the reversed view, it should go at the front of the base map. And putAll() should follow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1149933611


From smarks at openjdk.org  Tue Mar 28 02:37:22 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 28 Mar 2023 02:37:22 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
Message-ID: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>

> PR for Sequenced Collections implementation.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Simplify handling of cached keySet, values, and entrySet views.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/7387/files
  - new: https://git.openjdk.org/jdk/pull/7387/files/91c4eabe..3b7762d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7387&range=02-03

  Stats: 18 lines in 1 file changed: 6 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/7387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/7387/head:pull/7387

PR: https://git.openjdk.org/jdk/pull/7387


From alanb at openjdk.org  Tue Mar 28 06:56:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 06:56:35 GMT
Subject: RFR: 8304501: Remove orphaned demo netbeans projects [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Mar 2023 11:24:12 GMT, Eirik Bjorsnos  wrote:

>> Please review this PR which suggests we remove the orhphaned `SwingApplet` netbeans project directory.
>> 
>> The `SwingApplet` demo was removed in [JDK-8205119](https://bugs.openjdk.org/browse/JDK-8205119), but the netbeans projects files were left behind.
>> 
>> Additionally, the following netbeans projects reference source files that do not exist (if they ever did?):
>> 
>> - src/demo/share/nbproject/management/FullThreadDump
>> - src/demo/share/nbproject/management/JTop
>> - src/demo/share/nbproject/management/MemoryMonitor
>> - src/demo/share/nbproject/management/VerboseGC
>> - src/demo/share/nbproject/scripting/jconsole-plugin
>> 
>> The PR deletes files in these directories as well.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete netbeans project files in src/demo/share/nbproject/management and src/demo/share/nbproject/scripting

These were demo/sample code in JDK 5.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13098#pullrequestreview-1360326207


From duke at openjdk.org  Tue Mar 28 08:40:32 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Mar 2023 08:40:32 GMT
Subject: RFR: 8304501: Remove orphaned demo netbeans projects [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 28 Mar 2023 06:53:30 GMT, Alan Bateman  wrote:

> These were demo/sample code in JDK 5.

@mrserb would you please confirm if your review approval applies to `SwingApplet` only or the whole PR? As it stands, it is not clear to me whether this PR is approved or not. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13098#issuecomment-1486445336


From rriggs at openjdk.org  Tue Mar 28 18:11:23 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Mar 2023 18:11:23 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module
Message-ID: 

Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.

-------------

Commit messages:
 - Remove unused os.arch system property
 - Apply OperatingSystem enum instead of os.name to java.desktop module

Changes: https://git.openjdk.org/jdk/pull/13213/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13213&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304912
  Stats: 105 lines in 15 files changed: 19 ins; 39 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/13213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13213/head:pull/13213

PR: https://git.openjdk.org/jdk/pull/13213


From aturbanov at openjdk.org  Tue Mar 28 19:47:34 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 28 Mar 2023 19:47:34 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module
In-Reply-To: 
References: 
Message-ID: <5x6woAVFVGG7KNVf11uThxCM6SSg4O1OwBvUCnX96a4=.6cf8c161-0292-46b8-82c7-35a0ef29973e@github.com>

On Tue, 28 Mar 2023 17:59:31 GMT, Roger Riggs  wrote:

> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.

sun.awt.OSInfo could be cleanup up:
1. sun.awt.OSInfo#getOSTypeAction - is unused now
2. sun.awt.OSInfo#getOSType could use `OperatingSystem` method instead of relying of sun.awt.OSInfo#OS_NAME property. It seems it's used only in one place - sun.awt.X11.MotifColorUtilities#loadSystemColorsForCDE

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13213#issuecomment-1487500450


From aturbanov at openjdk.org  Tue Mar 28 19:53:37 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 28 Mar 2023 19:53:37 GMT
Subject: RFR: 8304947: Unnecessary Vector usage in java.awt.MenuBar.shortcuts
Message-ID: 

Method `'java.awt.MenuBar#shortcuts` creates a 'Vector', fills it and then returns its 'Enumeration elements()' as return value.
Instead of usage of legacy synchronized Vector here we can use ArrayList instead. Wrap it in Collections.enumeration to adapt to 'Enumeration' result type.

-------------

Commit messages:
 - [PATCH] Unnecessary Vector usage in java.awt.MenuBar.shortcuts

Changes: https://git.openjdk.org/jdk/pull/13149/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13149&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304947
  Stats: 13 lines in 2 files changed: 3 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13149.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13149/head:pull/13149

PR: https://git.openjdk.org/jdk/pull/13149


From serb at openjdk.org  Tue Mar 28 19:53:39 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Mar 2023 19:53:39 GMT
Subject: RFR: 8304947: Unnecessary Vector usage in
 java.awt.MenuBar.shortcuts
In-Reply-To: 
References: 
Message-ID: <9qApaWYTdRGbRA7J_m5H3-HQkvzzHqfzcADfxdo4IAw=.903c3fd8-d8a0-4c3d-ab39-76e3a4d3f487@github.com>

On Wed, 22 Mar 2023 19:12:34 GMT, Andrey Turbanov  wrote:

> Method `'java.awt.MenuBar#shortcuts` creates a 'Vector', fills it and then returns its 'Enumeration elements()' as return value.
> Instead of usage of legacy synchronized Vector here we can use ArrayList instead. Wrap it in Collections.enumeration to adapt to 'Enumeration' result type.

looks fine then

src/java.desktop/share/classes/java/awt/MenuBar.java line 350:

> 348:             }
> 349:         }
> 350:         return shortcuts.elements();

Can you please confirm the old and new enumerations have the same behavior during iteration/adding/removing/etc elements?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13149#issuecomment-1483351227
PR Review Comment: https://git.openjdk.org/jdk/pull/13149#discussion_r1146902747


From aturbanov at openjdk.org  Tue Mar 28 19:53:42 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 28 Mar 2023 19:53:42 GMT
Subject: RFR: 8304947: Unnecessary Vector usage in
 java.awt.MenuBar.shortcuts
In-Reply-To: 
References: 
Message-ID: <6IbDNq3LTpJGLcn9WvuKnW_VfdDAr46s7hyMJaIlal0=.9e39cf30-2f76-4e33-b3c6-174bfa0bcbdb@github.com>

On Wed, 22 Mar 2023 19:12:34 GMT, Andrey Turbanov  wrote:

> Method `'java.awt.MenuBar#shortcuts` creates a 'Vector', fills it and then returns its 'Enumeration elements()' as return value.
> Instead of usage of legacy synchronized Vector here we can use ArrayList instead. Wrap it in Collections.enumeration to adapt to 'Enumeration' result type.

src/java.desktop/share/classes/java/awt/Menu.java line 491:

> 489:     }
> 490: 
> 491:     synchronized Enumeration shortcuts() {

Can we change return type to `List` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13149#discussion_r1147183464


From aturbanov at openjdk.org  Tue Mar 28 19:53:44 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 28 Mar 2023 19:53:44 GMT
Subject: RFR: 8304947: Unnecessary Vector usage in
 java.awt.MenuBar.shortcuts
In-Reply-To: <9qApaWYTdRGbRA7J_m5H3-HQkvzzHqfzcADfxdo4IAw=.903c3fd8-d8a0-4c3d-ab39-76e3a4d3f487@github.com>
References: 
 <9qApaWYTdRGbRA7J_m5H3-HQkvzzHqfzcADfxdo4IAw=.903c3fd8-d8a0-4c3d-ab39-76e3a4d3f487@github.com>
Message-ID: <9P92DOsxDifilbuIc3dJJofxyd9EYO4YfERjQ4fHvHI=.1ffec142-7706-47e1-947f-930eca540d19@github.com>

On Thu, 23 Mar 2023 21:44:56 GMT, Sergey Bylokhov  wrote:

>> Method `'java.awt.MenuBar#shortcuts` creates a 'Vector', fills it and then returns its 'Enumeration elements()' as return value.
>> Instead of usage of legacy synchronized Vector here we can use ArrayList instead. Wrap it in Collections.enumeration to adapt to 'Enumeration' result type.
>
> src/java.desktop/share/classes/java/awt/MenuBar.java line 350:
> 
>> 348:             }
>> 349:         }
>> 350:         return shortcuts.elements();
> 
> Can you please confirm the old and new enumerations have the same behavior during iteration/adding/removing/etc elements?

Behavior is the same.
`Enumeration` doesn't have `remove` method. Only `hasMoreElements` and `nextElement`.
Method creates a new collection for result each time, hence no updates of underlying collection are possible.
Iteration order is the same too.

        Vector v = new Vector<>();
        v.add("123");
        v.add("444");
        v.add("555");
        v.add("666");

        Enumeration elements = v.elements();
        while (elements.hasMoreElements()) {
            String s = elements.nextElement();
            System.out.println(s);
        }
        System.out.println();

        ArrayList a = new ArrayList<>(v);
        Enumeration e = Collections.enumeration(a);
        while (e.hasMoreElements()) {
            String s = e.nextElement();
            System.out.println(s);
        }

gives

123
444
555
666

123
444
555
666

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13149#discussion_r1147173563


From serb at openjdk.org  Tue Mar 28 19:53:45 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Mar 2023 19:53:45 GMT
Subject: RFR: 8304947: Unnecessary Vector usage in
 java.awt.MenuBar.shortcuts
In-Reply-To: <9P92DOsxDifilbuIc3dJJofxyd9EYO4YfERjQ4fHvHI=.1ffec142-7706-47e1-947f-930eca540d19@github.com>
References: 
 <9qApaWYTdRGbRA7J_m5H3-HQkvzzHqfzcADfxdo4IAw=.903c3fd8-d8a0-4c3d-ab39-76e3a4d3f487@github.com>
 <9P92DOsxDifilbuIc3dJJofxyd9EYO4YfERjQ4fHvHI=.1ffec142-7706-47e1-947f-930eca540d19@github.com>
Message-ID: <74eVKWA0XvLn_Xan2yoWTqjDAiRZFDX1wwLaTcyCNlE=.3effeca6-fa29-4b9c-90cc-a0d4e401b4f2@github.com>

On Fri, 24 Mar 2023 06:37:35 GMT, Andrey Turbanov  wrote:

>> src/java.desktop/share/classes/java/awt/MenuBar.java line 350:
>> 
>>> 348:             }
>>> 349:         }
>>> 350:         return shortcuts.elements();
>> 
>> Can you please confirm the old and new enumerations have the same behavior during iteration/adding/removing/etc elements?
>
> Behavior is the same.
> `Enumeration` doesn't have `remove` method. Only `hasMoreElements` and `nextElement`.
> Method creates a new collection for result each time, hence no updates of underlying collection are possible.
> Iteration order is the same too.
> 
>         Vector v = new Vector<>();
>         v.add("123");
>         v.add("444");
>         v.add("555");
>         v.add("666");
> 
>         Enumeration elements = v.elements();
>         while (elements.hasMoreElements()) {
>             String s = elements.nextElement();
>             System.out.println(s);
>         }
>         System.out.println();
> 
>         ArrayList a = new ArrayList<>(v);
>         Enumeration e = Collections.enumeration(a);
>         while (e.hasMoreElements()) {
>             String s = e.nextElement();
>             System.out.println(s);
>         }
> 
> gives
> 
> 123
> 444
> 555
> 666
> 
> 123
> 444
> 555
> 666

but there is an asIterator method that may support remove

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13149#discussion_r1147201392


From aturbanov at openjdk.org  Tue Mar 28 19:53:46 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 28 Mar 2023 19:53:46 GMT
Subject: RFR: 8304947: Unnecessary Vector usage in
 java.awt.MenuBar.shortcuts
In-Reply-To: <74eVKWA0XvLn_Xan2yoWTqjDAiRZFDX1wwLaTcyCNlE=.3effeca6-fa29-4b9c-90cc-a0d4e401b4f2@github.com>
References: 
 <9qApaWYTdRGbRA7J_m5H3-HQkvzzHqfzcADfxdo4IAw=.903c3fd8-d8a0-4c3d-ab39-76e3a4d3f487@github.com>
 <9P92DOsxDifilbuIc3dJJofxyd9EYO4YfERjQ4fHvHI=.1ffec142-7706-47e1-947f-930eca540d19@github.com>
 <74eVKWA0XvLn_Xan2yoWTqjDAiRZFDX1wwLaTcyCNlE=.3effeca6-fa29-4b9c-90cc-a0d4e401b4f2@github.com>
Message-ID: 

On Fri, 24 Mar 2023 07:21:27 GMT, Sergey Bylokhov  wrote:

>> Behavior is the same.
>> `Enumeration` doesn't have `remove` method. Only `hasMoreElements` and `nextElement`.
>> Method creates a new collection for result each time, hence no updates of underlying collection are possible.
>> Iteration order is the same too.
>> 
>>         Vector v = new Vector<>();
>>         v.add("123");
>>         v.add("444");
>>         v.add("555");
>>         v.add("666");
>> 
>>         Enumeration elements = v.elements();
>>         while (elements.hasMoreElements()) {
>>             String s = elements.nextElement();
>>             System.out.println(s);
>>         }
>>         System.out.println();
>> 
>>         ArrayList a = new ArrayList<>(v);
>>         Enumeration e = Collections.enumeration(a);
>>         while (e.hasMoreElements()) {
>>             String s = e.nextElement();
>>             System.out.println(s);
>>         }
>> 
>> gives
>> 
>> 123
>> 444
>> 555
>> 666
>> 
>> 123
>> 444
>> 555
>> 666
>
> but there is an asIterator method that may support remove

`Vector.elements()` and `Collections.enumeration(ArrayList)` returns `Enumeration` implementations that don't override `asIterator` method. Default implementation `java.util.Enumeration#asIterator` doesn't support remove too.
So, we are safe here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13149#discussion_r1147979096


From rriggs at openjdk.org  Tue Mar 28 20:09:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Mar 2023 20:09:31 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 17:59:31 GMT, Roger Riggs  wrote:

> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.

> * sun.awt.OSInfo#getOSTypeAction - is unused now
> 
> * sun.awt.OSInfo#getOSType could use `OperatingSystem` method instead of relying of sun.awt.OSInfo#OS_NAME property. It seems it's used only in one place - sun.awt.X11.MotifColorUtilities#loadSystemColorsForCDE

OSInfo.getOSType() is used by some (1) tests; those references will need to be remediated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13213#issuecomment-1487524189


From forax at openjdk.org  Tue Mar 28 21:34:47 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 28 Mar 2023 21:34:47 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
 
Message-ID: 

On Tue, 28 Mar 2023 00:01:27 GMT, Stuart Marks  wrote:

>> This change is absolutely massive, implementing reversed() basically doubles the number of implementations which means multiple years of debugging / spec fixing.
>> 
>> Reversing a List makes sense, reversing a LinkedHashSet/LinkedHashMap is a nice to have. Having the concept of first and last (getFirst()/getLast()/etc) on Collection is something long awaited. 
>> 
>> I understand that wanting to separate the concept of Collection and SequencedCollection can be conceptually nice, but 
>> multiplying the number of interfaces also multiplies the number of implementations. Pragmatically, this patch is too big compared to how useful it is.
>> 
>> I get that Oracle is rich, but this JEP is not only a burden for Oracle but for the whole community.
>
> @forax 
> 
> Funnily, I was thinking the other day that this change is quite small given that I've been working on it for over two years. :-)
> 
> Anyway, thanks for looking through the implementation.

@stuart-marks, i read your message as not too not far from the sunken cost fallacy.

I still believe that introducing an interface for the concept of sequenced collection makes this change far bigger that it could be. After all, there is no interface for non-null collections, read-only collections, non structurally modifiable collections or sorted collections, so why an interface for ordered collection ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1487621122


From honkar at openjdk.org  Wed Mar 29 00:14:22 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 29 Mar 2023 00:14:22 GMT
Subject: RFR: JDK-8304991: Redundant hyphen in @param results in double-dash in
 javadocs
Message-ID: 

Minor change to Javadoc. Removed redundant hyphen for @param.

-------------

Commit messages:
 - removed extra hyphen

Changes: https://git.openjdk.org/jdk/pull/13218/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13218&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304991
  Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13218.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13218/head:pull/13218

PR: https://git.openjdk.org/jdk/pull/13218


From duke at openjdk.org  Wed Mar 29 04:26:40 2023
From: duke at openjdk.org (ScientificWare)
Date: Wed, 29 Mar 2023 04:26:40 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v29]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Feb 2023 21:56:28 GMT, ScientificWare  wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java
>   
>   Remove space.
>   
>   Co-authored-by: Alexey Ivanov 

Delay due to the reorganization of my contribution schedule caused by new requests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9825#issuecomment-1487926513


From psadhukhan at openjdk.org  Wed Mar 29 04:40:30 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 29 Mar 2023 04:40:30 GMT
Subject: RFR: JDK-8304991: Redundant hyphen in @param results in
 double-dash in javadocs
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Mar 2023 00:06:32 GMT, Harshitha Onkar  wrote:

> Minor change to Javadoc. Removed redundant hyphen for @param.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13218#pullrequestreview-1362239864


From duke at openjdk.org  Wed Mar 29 06:55:47 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 29 Mar 2023 06:55:47 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
 
 
Message-ID: 

On Tue, 28 Mar 2023 21:31:20 GMT, R?mi Forax  wrote:

> After all, there is no interface for non-null collections, read-only collections, non structurally modifiable collections or sorted collections, so why an interface for ordered collection ?

There is?`SortedMap`, and?non?null collection?interfaces are?unnecessary with?[JEP?draft: Null?Restricted and?Nullable?Types (Preview)][JEP?8303099].

[JEP?8303099]: https://openjdk.org/jeps/8303099 "JEP?draft: Null?Restricted and?Nullable?Types (Preview)"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488036900


From forax at openjdk.org  Wed Mar 29 09:55:07 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 29 Mar 2023 09:55:07 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 06:52:35 GMT, ExE Boss  wrote:

> There is SortedMap, 
yes, but no sorted "collection". An interface with a special semantic for set, map or list do not have the same impact in term of number of lines to maintain than a collection with a special semantics.

And java.util.Collection is a kind like java.lang.Object, it does not define a real semantics, equals/hashCode are defined in set and list not collection, so it's more that Collection is defined by its lack of semantics. So the same way, it's weird to have two java.lang.Object, it's weird to have two Collections.

> and non?null collection interfaces are unnecessary with JEP Null?Restricted and Nullable Types
i think we are agreeing here, there is no need for a special interface for non-null collections, so why do we need one for ordered collections.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488287644


From duke at openjdk.org  Wed Mar 29 10:40:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 10:40:17 GMT
Subject: RFR: 8266571: Sequenced Collections [v2]
In-Reply-To: <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
 <7hyZMdc6JI-92HcIQyh4gFMimualCSo-kSuApHjRPks=.4d53a75e-9caa-448d-a087-d1a03da8130a@github.com>
Message-ID: 

On Sat, 25 Mar 2023 08:19:18 GMT, R?mi Forax  wrote:

> I get that Oracle is rich, but this JEP is not only a burden for Oracle but for the whole community.

I'm going to have to call you out on this one, Remi.

Since both of us are non-native Enlish speakers, I'm going to define "calling out" as drawing critical attention to someone's unacceptable actions or behaviour.

I think judging a contribution based on the contributor's payslip is unacceptable. Some of us might be payed by Oracle. Some by other commercial companies. Some of us don't even have payslips. We're all contributors. Our work should be judged by technical  merits, not payslips.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488352086


From forax at openjdk.org  Wed Mar 29 11:31:22 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 29 Mar 2023 11:31:22 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: <2aOEUKoRMGzd9OgSr7www_FPNVczFnP_E7DI4nWITfk=.744a9e1c-79e9-4e77-af5f-fbcd62b3fd01@github.com>

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

Hi Erik,
I think you misunderstood me, currently Oracle supports most of the development of the OpenJDK financially, that's a fact and i'm glad that Oracle has taken that mantle because I'm remembering very well the sad state of Java at the time SUN was dying. 

I believe that introducing the interface SequencedCollection instead of adding the methods to Collection (i get it's not the exact same semantics) have an impact that is too big and will require more work than it should for both the maintainers of the JDK and the maintainers of the libraries having their own implementations of the Java collections.

This has nothing to do with the paycheck of some of us.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488423778


From duke at openjdk.org  Wed Mar 29 12:10:54 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 12:10:54 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <2aOEUKoRMGzd9OgSr7www_FPNVczFnP_E7DI4nWITfk=.744a9e1c-79e9-4e77-af5f-fbcd62b3fd01@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 <2aOEUKoRMGzd9OgSr7www_FPNVczFnP_E7DI4nWITfk=.744a9e1c-79e9-4e77-af5f-fbcd62b3fd01@github.com>
Message-ID: 

On Wed, 29 Mar 2023 11:28:39 GMT, R?mi Forax  wrote:

> Hi Erik, I think you misunderstood me, currently Oracle supports most of the development of the OpenJDK financially, that's a fact and i'm glad that Oracle has taken that mantle because I'm remembering very well the sad state of Java at the time SUN was dying.

Please do not avoid critisism by claiming to be misunderstood. This just annoys me. I'm presenting you feedback. Rather direct and tough feedback, I'll admit. Please embrace this opportunity to improve rather than drafting your defence.   

> I believe that introducing the interface SequencedCollection instead of adding the methods to Collection (i get it's not the exact same semantics) have an impact that is too big and will require more work than it should for both the maintainers of the JDK and the maintainers of the libraries having their own implementations of the Java collections.

Then just say so.
 
> This has nothing to do with the paycheck of some of us.

Fine, then let's agree to try and avoid using that paycheck as an argument for or against the merit of any PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488481290


From duke at openjdk.org  Wed Mar 29 12:23:39 2023
From: duke at openjdk.org (ScientificWare)
Date: Wed, 29 Mar 2023 12:23:39 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 5 Feb 2023 09:55:27 GMT, ScientificWare  wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
>> 
>> This is tracked in JBS as 
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
>> 
>> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
>> 
>> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)
>
> ScientificWare has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updates copyright date.
>    
>    Updates copyright date to 2023.
>  - Updates copyright date.
>    
>    Updates copyright date to 2023.

Delay due to the reorganization of my contribution schedule caused by new requests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10317#issuecomment-1488500678


From forax at openjdk.org  Wed Mar 29 13:13:05 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 29 Mar 2023 13:13:05 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: 

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

This is taking a personal turn and I do not see the point of discussing that matter here, so please send me an email at forax at univ-mlv.fr

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488580845


From duke at openjdk.org  Wed Mar 29 13:20:14 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 29 Mar 2023 13:20:14 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: 

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

> This is taking a personal turn and I do not see the point of discussing that matter here, so please send me an email at [forax at univ-mlv.fr](mailto:forax at univ-mlv.fr)

I agree we have both made our case and that a further discussion in this PR is becoming increasingly moot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1488595053


From avu at openjdk.org  Wed Mar 29 14:50:50 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Wed, 29 Mar 2023 14:50:50 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if created
 during display sleep
Message-ID: 

Use one display link thread per MTLContext. Adjust the refresh rate with the current display.

-------------

Commit messages:
 - 8304825: MacOS metal pipeline - window isn't painted if created during display sleep

Changes: https://git.openjdk.org/jdk/pull/13230/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13230&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304825
  Stats: 162 lines in 6 files changed: 107 ins; 29 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/13230.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13230/head:pull/13230

PR: https://git.openjdk.org/jdk/pull/13230


From honkar at openjdk.org  Wed Mar 29 16:53:57 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 29 Mar 2023 16:53:57 GMT
Subject: Integrated: JDK-8304991: Redundant hyphen in @param results in
 double-dash in javadocs
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Mar 2023 00:06:32 GMT, Harshitha Onkar  wrote:

> Minor change to Javadoc. Removed redundant hyphen for @param.

This pull request has now been integrated.

Changeset: 42df1a99
Author:    Harshitha Onkar 
URL:       https://git.openjdk.org/jdk/commit/42df1a99b7dc4203629150792c3f93469b315195
Stats:     5 lines in 4 files changed: 0 ins; 0 del; 5 mod

8304991: Redundant hyphen in @param results in double-dash in javadocs

Reviewed-by: psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/13218


From liach at openjdk.org  Wed Mar 29 19:10:03 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 19:10:03 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: 

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

src/java.base/share/classes/java/util/SequencedCollection.java line 107:

> 105:      */
> 106:     default void addFirst(E e) {
> 107:         throw new UnsupportedOperationException();

Can this be defaulted to `this.reversed().addLast()` instead? If this throws uoe, the reversed should throw uoe as well; and the new default can simplify implementations by much as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152372181


From forax at openjdk.org  Wed Mar 29 19:23:06 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 29 Mar 2023 19:23:06 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 19:06:20 GMT, Chen Liang  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify handling of cached keySet, values, and entrySet views.
>
> src/java.base/share/classes/java/util/SequencedCollection.java line 107:
> 
>> 105:      */
>> 106:     default void addFirst(E e) {
>> 107:         throw new UnsupportedOperationException();
> 
> Can this be defaulted to `this.reversed().addLast()` instead? If this throws uoe, the reversed should throw uoe as well; and the new default can simplify implementations by much as well.

In the same spirit, `reversed()` should also have a default implementation equivalent to

  Collections.unmodifiableSequenceCollection(Arrays.asList(this.toArray())).reversed()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152384938


From tvaleev at openjdk.org  Wed Mar 29 19:58:17 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 29 Mar 2023 19:58:17 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
 
Message-ID: 

On Wed, 29 Mar 2023 19:20:16 GMT, R?mi Forax  wrote:

>> src/java.base/share/classes/java/util/SequencedCollection.java line 107:
>> 
>>> 105:      */
>>> 106:     default void addFirst(E e) {
>>> 107:         throw new UnsupportedOperationException();
>> 
>> Can this be defaulted to `this.reversed().addLast()` instead? If this throws uoe, the reversed should throw uoe as well; and the new default can simplify implementations by much as well.
>
> In the same spirit, `reversed()` should also have a default implementation equivalent to
> 
>   Collections.unmodifiableSequenceCollection(Arrays.asList(this.toArray())).reversed()

@forax but this would not be a view: changes in the underlying collection won't be reflected

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152416692


From forax at openjdk.org  Wed Mar 29 20:08:31 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 29 Mar 2023 20:08:31 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 19:54:48 GMT, Tagir F. Valeev  wrote:

>> In the same spirit, `reversed()` should also have a default implementation equivalent to
>> 
>>   Collections.unmodifiableSequenceCollection(Arrays.asList(this.toArray())).reversed()
>
> @forax but this would not be a view: changes in the underlying collection won't be reflected

Yes,
The spec says :"Changes to the underlying collection might or might not be visible in this reversed view, depending upon the implementation." so i believe the default implementation i proposed is a valid implementation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152426988


From liach at openjdk.org  Wed Mar 29 21:58:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 21:58:50 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: 

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

In the JEP:
> A sequenced collection supports common operations at either end, and it supports processing the elements from first to last and from last to first (i.e., forward and reverse).

> The reverse-ordered view enables all the different sequenced types to process elements in both directions, using all the usual iteration mechanisms: Enhanced for loops, explicit iterator() loops, forEach(), stream(), parallelStream(), and toArray().

This implies that for the reversed view, collection operations are not only supported, but can potentially be optimized. Our design should anticipate implementations of `SequencedCollection` to provide specific reversed implementations, like what we are already doing with `addAll` in ArrayList and ArrayDeque. If a collection cannot have efficient reverse-sequenced operations, it shouldn't be retrofitted into `SequencedCollection`, just like how we don't fit Deques into Lists.

Hence, I recommend:
1. Declare `reversed()` and one of the (First/Last) operation sets (add|get|remove) `abstract`, and delegae the other set to default call the operation on the reversed instead. 
   - Since we tend to work with the end of collections, I'd declare the `Last` methods to be abstract and delegate the `First` default implementations to `this.reversed().xxxLast()`
2. I don't think leaving `addLast()` implemented by default is a good idea, for modifiable implementations cannot discover that they missed the `addLast()` at compile time and can only discover when the implementation is actually used.
3. In the default `reversed()` implementation of `List` and `Deque`, add API notes to indicate to implementations opportunities to optimize the implementation, especially batch operations like `addAll` when the base implementation offers such an optimization.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1489338414


From liach at openjdk.org  Wed Mar 29 21:59:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Mar 2023 21:59:08 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 20:05:10 GMT, R?mi Forax  wrote:

>> @forax but this would not be a view: changes in the underlying collection won't be reflected
>
> Yes,
> The spec says :"Changes to the underlying collection might or might not be visible in this reversed view, depending upon the implementation." so i believe the default implementation i proposed is a valid implementation

In the JEP, it says:
> Any modifications to the original collection are visible in the view.

If we don't have an efficient reversed view, I don't see a point of declaring a collection sequenced; same reason for declaring a sequenced/deque vs. a full-on list with inefficient list random access operations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152474419


From forax at openjdk.org  Wed Mar 29 21:59:08 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 29 Mar 2023 21:59:08 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
 
 
 
 
Message-ID: 

On Wed, 29 Mar 2023 20:54:15 GMT, Chen Liang  wrote:

>> Yes,
>> The spec says :"Changes to the underlying collection might or might not be visible in this reversed view, depending upon the implementation." so i believe the default implementation i proposed is a valid implementation
>
> In the JEP, it says:
>> Any modifications to the original collection are visible in the view.
> 
> If we don't have an efficient reversed view, I don't see a point of declaring a collection sequenced; same reason for declaring a sequenced/deque vs. a full-on list with inefficient list random access operations.

The quote is from the javadoc of reversed (see above), it seems the JEP and the javadoc disagree :(

> If we don't have an efficient reversed view, I don't see a point of declaring a collection sequenced

Collections in the JDK provides more efficient implementations, this is what the code this PR does.
Providing a default implementation matters more for external libraries.

And that's why i think we do not need the interface SequencedCollection, because all these methods can be declared on Collection instead. Adding them on Collection has also the added benefit that as a user, all Clojure collections or any other implementations not in the JDK also get a good enough implementation of the method reversed().

My fear is that if we introduce all these methods on SequencedCollection instead of Collection, library implementations will never be updated to use SequencedCollection instead of Collection (because implementing SequencedCollection requires the library to work only on JDK 21+) while if reversed is declared on Collection, library maintainers will have more pressure to write an efficient implementation of reversed for their implementations (and will be able to do that without requiring the JDK 21).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152494872


From liach at openjdk.org  Thu Mar 30 00:49:34 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Mar 2023 00:49:34 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
 
 
 
 
 
Message-ID: <9pJ43hfjRd9PuedB__Q7ziY-_8PzPIlfHwUUQEZN4vo=.1d3edbca-0bde-4e11-a223-c31f2a556a94@github.com>

On Wed, 29 Mar 2023 21:18:04 GMT, R?mi Forax  wrote:

>> In the JEP, it says:
>>> Any modifications to the original collection are visible in the view.
>> 
>> If we don't have an efficient reversed view, I don't see a point of declaring a collection sequenced; same reason for declaring a sequenced/deque vs. a full-on list with inefficient list random access operations.
>
> The quote is from the javadoc of reversed (see above), it seems the JEP and the javadoc disagree :(
> 
>> If we don't have an efficient reversed view, I don't see a point of declaring a collection sequenced
> 
> Collections in the JDK provides more efficient implementations, this is what the code this PR does.
> Providing a default implementation matters more for external libraries.
> 
> And that's why i think we do not need the interface SequencedCollection, because all these methods can be declared on Collection instead. Adding them on Collection has also the added benefit that as a user, all Clojure collections or any other implementations not in the JDK also get a good enough implementation of the method reversed().
> 
> My fear is that if we introduce all these methods on SequencedCollection instead of Collection, library implementations will never be updated to use SequencedCollection instead of Collection (because implementing SequencedCollection requires the library to work only on JDK 21+) while if reversed is declared on Collection, library maintainers will have more pressure to write an efficient implementation of reversed for their implementations (and will be able to do that without requiring the JDK 21).

So your model would be like:

public interface Collection ... {
    ...
    default Collection reversed() {...} // - can dump to array
    default void addLast() {...} // or addFirst - no reliable impl
    default boolean removeLast() {...} // or removeFirst - no reliable impl
    default T getLast() {...} // or getFirst - can dump to array
}

I don't think `reversed()` is the problem here; `addLast` `removeLast` cannot be implemented from the existing Collection methods without risking contract violations, so I don't recommend leaving them as default methods. I still think SequencedCollection should exist for its specification of add/removeLast and improved performance of getLast.

That said, it is true that SequencedCollection as an interface itself has less merit as unmodifiable/immutable collections. It will only work as a marker indicating the contract that an encounter sequence is defined.

For libraries, they can use version-specific class files in META-INF; to un-sequence a collection implementation should be quite simple, as nuking the bridge `reversed` returning `SequencedCollection` and the `SequencedCollection` symbol from interface lists. This can be done with a simple classfile transformer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152623381


From smarks at openjdk.org  Thu Mar 30 06:34:44 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 30 Mar 2023 06:34:44 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 13:09:52 GMT, R?mi Forax  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify handling of cached keySet, values, and entrySet views.
>
> This is taking a personal turn and I do not see the point of discussing that matter here, so please send me an email at forax at univ-mlv.fr

@forax 
>  i read your message as not too not far from the sunken cost fallacy.

No, not at all. I'm saying that after two years, the PR is only about 7,000 lines of changes. That's quite a bit smaller than several other PRs, contrary to your statement that it is "massive." It's not.

I'm not going to relitigate the design issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1489768106


From smarks at openjdk.org  Thu Mar 30 06:44:31 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 30 Mar 2023 06:44:31 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 21:18:02 GMT, Chen Liang  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify handling of cached keySet, values, and entrySet views.
>
> In the JEP:
>> A sequenced collection supports common operations at either end, and it supports processing the elements from first to last and from last to first (i.e., forward and reverse).
> 
>> The reverse-ordered view enables all the different sequenced types to process elements in both directions, using all the usual iteration mechanisms: Enhanced for loops, explicit iterator() loops, forEach(), stream(), parallelStream(), and toArray().
> 
> This implies that for the reversed view, collection operations are not only supported, but can potentially be optimized. Our design should anticipate implementations of `SequencedCollection` to provide specific reversed implementations, like what we are already doing with `addAll` in ArrayList and ArrayDeque. If a collection cannot have efficient reverse-sequenced operations, it shouldn't be retrofitted into `SequencedCollection`, just like how we don't fit Deques into Lists.
> 
> Hence, I recommend:
> 1. Declare `reversed()` and one of the (First/Last) operation sets (add|get|remove) `abstract`, and delegae the other set to default call the operation on the reversed instead. 
>    - Since we tend to work with the end of collections, I'd declare the `Last` methods to be abstract and delegate the `First` default implementations to `this.reversed().xxxLast()`
> 2. I don't think leaving `addLast()` implemented by default is a good idea, for modifiable implementations cannot discover that they missed the `addLast()` at compile time and can only discover when the implementation is actually used.
> 3. In the default `reversed()` implementation of `List` and `Deque`, add API notes to indicate to implementations opportunities to optimize the implementation, especially batch operations like `addAll` when the base implementation offers such an optimization.

@liach 

I understand that you're suggesting adding various default implementations in order to make it easier for people to bring up implementations of SequencedCollections. However, adding default implementations to SequencedCollection itself is unlikely to help. I expect that most implementations will override both addFirst and addLast. Requiring overriding of only one of them will hardly help anything, because the more difficult task is implementing the reverse-ordered view. I'd prefer to concentrate on some kind of implementation assistance for doing that. For example, there could be an "AbstractSequencedCollection" that would require overriding only a couple methods, rather like `AbstractCollection`. I'm a bit reluctant to introduce new abstract classes into the public API though. An alternative might be to have some kind of static factory method that takes something like a Collection and a reverse iterator and returns a SequencedCollection.

It's not clear to me that such support is necessary. It's pretty easy to bring up a List using AbstractList, and a List is a SequencedCollection. But if we do add something, it should be driven by use cases, and not speculation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1489776815


From aghaisas at openjdk.org  Thu Mar 30 06:56:14 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 30 Mar 2023 06:56:14 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: 
References: 
Message-ID: <6RbhSYb-6rfYCedu9ToWjRtcfp-gFThUujYQoFYoFiE=.e171de7e-ccea-4ad6-b793-8eb1235e03c4@github.com>

On Wed, 29 Mar 2023 14:39:12 GMT, Alexey Ushakov  wrote:

> Use one display link thread per MTLContext. Adjust the refresh rate with the current display.

I tested the test program of this bug and SwingSet2 - with and without external monitor attached.
- This patch fixes the reported issue. Also, I did not see any regression in SwingSet2 while moving the test window between external monitors. All regression tests also ran successfully with this patch.
- This patch has a negative impact on rendering performance.
SwingMark tests show very poor numbers on x64 based macs. There is a performance decrease on M1 macs as well.
I think, this has to do with removal of a dedicated `blitCommandQueue`. 

We need to address the performance degradation that this patch causes or look for a simpler solution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13230#issuecomment-1489788284


From avu at openjdk.org  Thu Mar 30 08:45:16 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Thu, 30 Mar 2023 08:45:16 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: 
References: 
Message-ID: <-vkDxX5NAnkDidENmShdBZtyR3Nn9ZNdTk2Oho53zag=.34ed8902-50bd-4c9e-98bd-b4094824bfed@github.com>

On Wed, 29 Mar 2023 14:39:12 GMT, Alexey Ushakov  wrote:

> Use one display link thread per MTLContext. Adjust the refresh rate with the current display.

Thanks for the testing. I've run only RenderPerf and only on M1 but it didn't show any regressions (there were some improvements actually) I've removed the dedicated blitCommandQueue because it caused the unpredicted order of rendered frames to appear on the screen. In general, it's recommended to use only one command queue per application. If we still want to use a separate queue, we need to provide some synchronization here https://developer.apple.com/documentation/metal/resource_synchronization/synchronizing_events_within_a_single_device?language=objc .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13230#issuecomment-1489922312


From avu at openjdk.org  Thu Mar 30 08:55:18 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Thu, 30 Mar 2023 08:55:18 GMT
Subject: RFR: 8304825: MacOS metal pipeline - window isn't painted if
 created during display sleep
In-Reply-To: <6RbhSYb-6rfYCedu9ToWjRtcfp-gFThUujYQoFYoFiE=.e171de7e-ccea-4ad6-b793-8eb1235e03c4@github.com>
References: 
 <6RbhSYb-6rfYCedu9ToWjRtcfp-gFThUujYQoFYoFiE=.e171de7e-ccea-4ad6-b793-8eb1235e03c4@github.com>
Message-ID: <6co54WQ1FA_lD9KZhw9eWhOh_0Tty6gyXx2SYthOA28=.ab716fe0-6e1c-43d5-b5ee-4659fb2f3f38@github.com>

On Thu, 30 Mar 2023 06:53:46 GMT, Ajit Ghaisas  wrote:

>> Use one display link thread per MTLContext. Adjust the refresh rate with the current display.
>
> I tested the test program of this bug and SwingSet2 - with and without external monitor attached.
> - This patch fixes the reported issue. Also, I did not see any regression in SwingSet2 while moving the test window between external monitors. All regression tests also ran successfully with this patch.
> - This patch has a negative impact on rendering performance.
> SwingMark tests show very poor numbers on x64 based macs. There is a performance decrease on M1 macs as well.
> I think, this has to do with removal of a dedicated `blitCommandQueue`. 
> 
> We need to address the performance degradation that this patch causes or look for a simpler solution.

@aghaisas could you return back the blit command queue in my patch and see if it resolves the performance issue with SwingMark? I'm not completely sure that it's the main reason for the performance degradation. Another possible reason is the increased amount of start/stop displaylink  calls because of changes in the logic that manages them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13230#issuecomment-1489936273


From tvaleev at openjdk.org  Thu Mar 30 09:56:40 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Thu, 30 Mar 2023 09:56:40 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
Message-ID: 

On Tue, 28 Mar 2023 02:37:22 GMT, Stuart Marks  wrote:

>> PR for Sequenced Collections implementation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify handling of cached keySet, values, and entrySet views.

src/java.base/share/classes/java/util/AbstractMap.java line 899:

> 897:      * @param  the view's element type
> 898:      */
> 899:     /* non-public */ static class ViewCollection implements Collection {

Should we declare it abstract to depict that this class is not intended to be instantiated directly?

src/java.base/share/classes/java/util/LinkedHashMap.java line 78:

> 76:  * on collection-views do not affect the order of iteration of the
> 77:  * backing map.
> 78:  *

I see above the list of methods that affect the encounter order in access-order mode:
> Invoking the put, putIfAbsent, get, getOrDefault, compute, computeIfAbsent, computeIfPresent, or merge methods results in an access...

Should we extend it to add new methods like putFirst and putLast? Also, it says that 'In particular, operations on collection-views do not affect the order of iteration of the backing map'. Now, we have a map-view (`reversed()`). We should specify whether operations on the reversed map change the encounter order of the original map, and if yes then how exactly they do this (moving entries to the end, like in the original map, or moving them to the beginning?)

src/java.base/share/classes/java/util/LinkedHashMap.java line 1189:

> 1187: 
> 1188:         public V putIfAbsent(K key, V value) {
> 1189:             return base.putIfAbsent(key, value);

`putIfAbsent` should also preserve insert at the beginning. The default implementation from the `Map` interface will actually work (though requires double lookup):


V v = get(key);
if (v == null) {
  v = put(key, value);
}
return v;

Or we can narrow it a little bit:

V v = base.get(key);
if (v == null) {
  v = base.putFirst(key, value);
}
return v;

src/java.base/share/classes/java/util/SequencedCollection.java line 45:

> 43:  * required to operate on elements in encounter order include the following:
> 44:  * {@link Iterable#forEach forEach}, {@link Collection#parallelStream parallelStream},
> 45:  * {@link Collection#spliterator spliterator}, {@link Collection#stream stream},

Should we require in specification that the implementations of `SequencedCollection::spliterator` must have the `ORDERED` charactersitic?

src/java.base/share/classes/java/util/SequencedCollection.java line 78:

> 76:  * @since 21
> 77:  */
> 78: public interface SequencedCollection extends Collection {

Should we narrow the specification for `Collection::add` here, saying that `add` is essentially `addLast`? Specification for deque mentions that `add` and `addLast` are equivalent. Otherwise, the implementation of `SequencedCollection::add` that adds the element to a random position will comply the spec.

Another thing is `remove(Object)`. Should we specify here that it will remove the first instance of Object inside the collection (like it's specified in the list)? Or is it allowed to return a random one?

src/java.base/share/classes/java/util/SequencedMap.java line 125:

> 123:  * @since 21
> 124:  */
> 125: public interface SequencedMap extends Map {

Again, it would be good to specify here the behavior of some old methods from `Map`. Methods `put`, `putIfAbsent`, `merge`, `compute`, and `computeIfAbsent` may add new mapping as well. Should we specify that for ordered map the mapping is added at the end of collection? Or is it at discretion of the implementation?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1153019190
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1153002016
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1153013781
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152981740
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152978206
PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152994927


From tvaleev at openjdk.org  Thu Mar 30 09:56:42 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Thu, 30 Mar 2023 09:56:42 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 
Message-ID: 

On Fri, 24 Mar 2023 21:39:09 GMT, Tagir F. Valeev  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify handling of cached keySet, values, and entrySet views.
>
> src/java.base/share/classes/java/util/LinkedHashMap.java line 1197:
> 
>> 1195: 
>> 1196:         public V computeIfAbsent(K key, Function mappingFunction) {
>> 1197:             return base.computeIfAbsent(key, mappingFunction);
> 
> Again, it's somewhat worrysome that methods like `computeIfAbsent` will actually add new nodes to the end of original LinkedHashMap instead of to the beginning. Probably not very big deal but looks inconsistent...

Likely, for the first iteration it's possible to remove specializations for compute*/merge methods and use the default implementation from the `Map` interface, which will properly insert the new item to the beginning (if we properly implement reversed `put`). Later it could be optimized if necessary. What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1153015878


From tvaleev at openjdk.org  Thu Mar 30 09:59:34 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Thu, 30 Mar 2023 09:59:34 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
 
Message-ID: 

On Thu, 30 Mar 2023 06:41:38 GMT, Stuart Marks  wrote:

>> In the JEP:
>>> A sequenced collection supports common operations at either end, and it supports processing the elements from first to last and from last to first (i.e., forward and reverse).
>> 
>>> The reverse-ordered view enables all the different sequenced types to process elements in both directions, using all the usual iteration mechanisms: Enhanced for loops, explicit iterator() loops, forEach(), stream(), parallelStream(), and toArray().
>> 
>> This implies that for the reversed view, collection operations are not only supported, but can potentially be optimized. Our design should anticipate implementations of `SequencedCollection` to provide specific reversed implementations, like what we are already doing with `addAll` in ArrayList and ArrayDeque. If a collection cannot have efficient reverse-sequenced operations, it shouldn't be retrofitted into `SequencedCollection`, just like how we don't fit Deques into Lists.
>> 
>> Hence, I recommend:
>> 1. Declare `reversed()` and one of the (First/Last) operation sets (add|get|remove) `abstract`, and delegae the other set to default call the operation on the reversed instead. 
>>    - Since we tend to work with the end of collections, I'd declare the `Last` methods to be abstract and delegate the `First` default implementations to `this.reversed().xxxLast()`
>> 2. I don't think leaving `addLast()` implemented by default is a good idea, for modifiable implementations cannot discover that they missed the `addLast()` at compile time and can only discover when the implementation is actually used.
>> 3. In the default `reversed()` implementation of `List` and `Deque`, add API notes to indicate to implementations opportunities to optimize the implementation, especially batch operations like `addAll` when the base implementation offers such an optimization.
>
> @liach 
> 
> I understand that you're suggesting adding various default implementations in order to make it easier for people to bring up implementations of SequencedCollections. However, adding default implementations to SequencedCollection itself is unlikely to help. I expect that most implementations will override both addFirst and addLast. Requiring overriding of only one of them will hardly help anything, because the more difficult task is implementing the reverse-ordered view. I'd prefer to concentrate on some kind of implementation assistance for doing that. For example, there could be an "AbstractSequencedCollection" that would require overriding only a couple methods, rather like `AbstractCollection`. I'm a bit reluctant to introduce new abstract classes into the public API though. An alternative might be to have some kind of static factory method that takes something like a Collection and a reverse iterator and returns a SequencedCollection.
> 
> It's not clear to me that such support is necessary. It's pretty easy to bring up a List using AbstractList, and a List is a SequencedCollection. But if we do add something, it should be driven by use cases, and not speculation.

@stuart-marks 

> Thanks for looking! I took a quick look through the comments and they seem reasonable. Right now I'm concentrating on the specification in order to get the CSR Finalized. Do you have any comments on the specifications? I'll take a look at the implementation comments afterward. Some I'll be able to address before integration, but some I might need to postpone until later.

The specification is mostly well-written, thanks! I've added a few comments on the spec and few more comments on the implementation. Please check.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1490024150


From liach at openjdk.org  Thu Mar 30 11:36:34 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Mar 2023 11:36:34 GMT
Subject: RFR: 8266571: Sequenced Collections [v4]
In-Reply-To: 
References: <2lOHgEj9uSIx1CXdKRFG1Jo3EFEe_yOwu69eFSiAHrE=.59e51a84-1a03-4cb6-9f0a-af96bd4ce0a8@github.com>
 <-BNnKi-AQ6XTBe-GxXIn9Zq7WdROvR9mX73H_gr2rs8=.4c034fa8-781f-4739-ade8-e24f507f55be@github.com>
 
Message-ID: 

On Wed, 29 Mar 2023 21:18:02 GMT, Chen Liang  wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify handling of cached keySet, values, and entrySet views.
>
> In the JEP:
>> A sequenced collection supports common operations at either end, and it supports processing the elements from first to last and from last to first (i.e., forward and reverse).
> 
>> The reverse-ordered view enables all the different sequenced types to process elements in both directions, using all the usual iteration mechanisms: Enhanced for loops, explicit iterator() loops, forEach(), stream(), parallelStream(), and toArray().
> 
> This implies that for the reversed view, collection operations are not only supported, but can potentially be optimized. Our design should anticipate implementations of `SequencedCollection` to provide specific reversed implementations, like what we are already doing with `addAll` in ArrayList and ArrayDeque. If a collection cannot have efficient reverse-sequenced operations, it shouldn't be retrofitted into `SequencedCollection`, just like how we don't fit Deques into Lists.
> 
> Hence, I recommend:
> 1. Declare `reversed()` and one of the (First/Last) operation sets (add|get|remove) `abstract`, and delegae the other set to default call the operation on the reversed instead. 
>    - Since we tend to work with the end of collections, I'd declare the `Last` methods to be abstract and delegate the `First` default implementations to `this.reversed().xxxLast()`
> 2. I don't think leaving `addLast()` implemented by default is a good idea, for modifiable implementations cannot discover that they missed the `addLast()` at compile time and can only discover when the implementation is actually used.
> 3. In the default `reversed()` implementation of `List` and `Deque`, add API notes to indicate to implementations opportunities to optimize the implementation, especially batch operations like `addAll` when the base implementation offers such an optimization.

> @liach
> 
> I understand that you're suggesting adding various default implementations in order to make it easier for people to bring up implementations of SequencedCollections. However, adding default implementations to SequencedCollection itself is unlikely to help. I expect that most implementations will override both addFirst and addLast. Requiring overriding of only one of them will hardly help anything, because the more difficult task is implementing the reverse-ordered view. I'd prefer to concentrate on some kind of implementation assistance for doing that. For example, there could be an "AbstractSequencedCollection" that would require overriding only a couple methods, rather like `AbstractCollection`. I'm a bit reluctant to introduce new abstract classes into the public API though. An alternative might be to have some kind of static factory method that takes something like a Collection and a reverse iterator and returns a SequencedCollection.
> 
> It's not clear to me that such support is necessary. It's pretty easy to bring up a List using AbstractList, and a List is a SequencedCollection. But if we do add something, it should be driven by use cases, and not speculation.

Then shouldn't we leave all methods in SewuencedCollection abstract as users almost always override them?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1490144021


From duke at openjdk.org  Thu Mar 30 15:51:25 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Thu, 30 Mar 2023 15:51:25 GMT
Subject: RFR: 8301616: Drag & maximize to another monitor places window
 incorrectly (Windows) [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Mar 2023 22:53:43 GMT, Sergey Bylokhov  wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8301616: Drag & maximize to another monitor places window incorrectly (Windows)
>
> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 374:
> 
>> 372:     WINDOWPOS * wp = (WINDOWPOS *)windowPos;
>> 373: 
>> 374:     // There's no good way to detect partial maximization (e.g. Aero Snap),
> 
> Does the bug affect all windows, or only frames/dialog? Can we move this code to the AwtFrame#WmWindowPosChanging?

I believe it should only affect frames and dialogs, but I don't understand, why it wasn't done for `CheckWindowDPIChange` in the first place, AFAIU this hack is only relevant for frames and dialogs as well. I can move this code into AwtFrame, but then I'd need to loosen visibility of `prevScaleRec` and `m_screenNum`, I personally don't think it worth it. What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12367#discussion_r1153462844


From serb at openjdk.org  Thu Mar 30 16:16:33 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 30 Mar 2023 16:16:33 GMT
Subject: Integrated: 8299333: Unify exceptions used by all variants of
 ICC_Profile.getInstance(null)
In-Reply-To: 
References: 
Message-ID: 

On Fri, 23 Dec 2022 23:32:45 GMT, Sergey Bylokhov  wrote:

> I tried to clean up the documentation in the `java.awt.color` package and specify how the `null` parameters are handled here and there. But it looks like the `ICC_profile` class is too specific so I would like to discuss it separately.
> 
> The ICC_Profile has these methods:
>  * `getInstance(int)`      - always throws specified `IllegalArgumentException` on the wrong constant
>  * `getInstance(byte[])` - always throws specified `IllegalArgumentException` on `null`
>  * `getInstance(String fileName)` - always throws unspecified `NullPointerException` on `null`
>  * `getInstance(InputStream)`      - thrown unspecified `NullPointerException` before [JDK-8227816](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388) and now throws specified but misleading `IOException: Stream closed` exception on `null`
> 
> So we have 3 methods that can get null as a parameter and each throw a different exception.
> 
> Note that all of the specs for the methods above have this part:
> 
>> @throws IllegalArgumentException If the stream does not contain valid ICC Profile data
> 
> So I have an idea to change `getInstance(String)` and `getInstance(InputStream)` to throw `IllegalArgumentException`  even if I personally prefer NPE to be thrown.
> 
> From another point of view the `ICC_Profile` profile has other methods:
>  * `write(String fileName)` - always throws unspecified `NullPointerException` on `null`
>  * `write(OutputStream) `  - always throws unspecified `NullPointerException` on `null`
> 
> I am not sure we can throw `IllegalArgumentException` from the `write` methods, so the specification for `getInstance(String)` and `getInstance(InputStream)` could be updated to throw NPE on null same as related `write`.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: d2df36b0
Author:    Sergey Bylokhov 
URL:       https://git.openjdk.org/jdk/commit/d2df36b073943fc85b169f09e32747ebe2ad0bfb
Stats:     86 lines in 2 files changed: 77 ins; 6 del; 3 mod

8299333: Unify exceptions used by all variants of ICC_Profile.getInstance(null)

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/11784


From duke at openjdk.org  Thu Mar 30 21:21:12 2023
From: duke at openjdk.org (Joshua Cao)
Date: Thu, 30 Mar 2023 21:21:12 GMT
Subject: RFR: 8304295: VM build fails with GCC 7 after JDK-8301998
Message-ID: 

Builds successfully with GCC 7


gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-------------

Commit messages:
 - 8304295: VM build fails with GCC 7 after JDK-8301998

Changes: https://git.openjdk.org/jdk/pull/13253/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13253&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304295
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13253/head:pull/13253

PR: https://git.openjdk.org/jdk/pull/13253


From duke at openjdk.org  Thu Mar 30 21:21:13 2023
From: duke at openjdk.org (Joshua Cao)
Date: Thu, 30 Mar 2023 21:21:13 GMT
Subject: RFR: 8304295: VM build fails with GCC 7 after JDK-8301998
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Mar 2023 21:05:40 GMT, Joshua Cao  wrote:

> Builds successfully with GCC 7
> 
> 
> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Bot is not filling in the PR. Did I input something wrong?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13253#issuecomment-1490968575


From serb at openjdk.org  Thu Mar 30 21:27:20 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 30 Mar 2023 21:27:20 GMT
Subject: RFR: 8304295: VM build fails with GCC 7 after JDK-8301998
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Mar 2023 21:05:40 GMT, Joshua Cao  wrote:

> Builds successfully with GCC 7
> 
> 
> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

If we will going forward with this patch, can we exclude the warning for the old compilers only? as was mentioned in the JBS the gcc10+ compiles that code fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13253#issuecomment-1490984429


From erikj at openjdk.org  Thu Mar 30 21:34:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 30 Mar 2023 21:34:17 GMT
Subject: RFR: 8304295: VM build fails with GCC 7 after JDK-8301998
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Mar 2023 21:24:02 GMT, Sergey Bylokhov  wrote:

> If we will going forward with this patch, can we exclude the warning for the old compilers only? as was mentioned in the JBS the gcc10+ compiles that code fine.

The build system doesn't have a convenient way of selectively disable warnings for different compiler versions. I recommend against trying to implement that here. 

If this library is all third-party code, does it really matter that much if we disable another warning? We aren't responsible for keeping this source warning free as we can't make changes to it to anyway.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13253#issuecomment-1490990819


From serb at openjdk.org  Fri Mar 31 04:49:14 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 31 Mar 2023 04:49:14 GMT
Subject: RFR: 8304295: VM build fails with GCC 7 after JDK-8301998
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Mar 2023 21:31:07 GMT, Erik Joelsson  wrote:

> > If we will going forward with this patch, can we exclude the warning for the old compilers only? as was mentioned in the JBS the gcc10+ compiles that code fine.
> 
> The build system doesn't have a convenient way of selectively disable warnings for different compiler versions. I recommend against trying to implement that here.
> 
> If this library is all third-party code, does it really matter that much if we disable another warning? We aren't responsible for keeping this source warning free as we can't make changes to it to anyway.

Isnt it is possible to check the TOOLCHAIN_TYPE+TOOLCHAIN_VERSION as we did here?:
https://github.com/openjdk/jdk/commit/347672464127a5d4dd847ba2a4ca30c5ff51b32c
Or we do not set such props for gcc?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13253#issuecomment-1491281764


From jwaters at openjdk.org  Fri Mar 31 05:57:01 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 31 Mar 2023 05:57:01 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v3]
In-Reply-To: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
Message-ID: 

> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Explicit conversion to jboolean

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13139/files
  - new: https://git.openjdk.org/jdk/pull/13139/files/3f9da8b6..362cf3ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13139&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13139&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13139/head:pull/13139

PR: https://git.openjdk.org/jdk/pull/13139


From jwaters at openjdk.org  Fri Mar 31 05:57:04 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 31 Mar 2023 05:57:04 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v3]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
 
Message-ID: 

On Fri, 24 Mar 2023 03:02:47 GMT, David Holmes  wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Explicit conversion to jboolean
>
> src/java.prefs/macosx/native/libprefs/MacOSXPreferencesFile.m line 685:
> 
>> 683:     CFStringRef topKey;
>> 684:     CFMutableDictionaryRef topValue;
>> 685:     Boolean beforeAdd = false;
> 
> The return value from `CFDictionaryContainsKey` is a Boolean and is assigned to this variable. So I think these changes are the wrong way round. Keep this as a Boolean but convert the return value to jboolean:
> 
> return beforeAdd ? JNI_TRUE : JNI_FALSE;

Argh, looks like Apple and Objective-C still use the ancient Boolean types from Carbon for the CoreFoundation APIs. Sigh...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13139#discussion_r1154042130


From dholmes at openjdk.org  Fri Mar 31 06:36:18 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 31 Mar 2023 06:36:18 GMT
Subject: RFR: 8304717: Declaration aliasing between boolean and jboolean is
 wrong [v3]
In-Reply-To: 
References: <9Xij1FEbLnMYTPIZOOhGyaKnlplxP6Wp3ODS2bKP7u0=.146017ce-32ee-40f3-8496-49c014f7decb@github.com>
 
Message-ID: 

On Fri, 31 Mar 2023 05:57:01 GMT, Julian Waters  wrote:

>> A couple of spots wrongly refer to boolean and jboolean as the same thing. While this does still compile thanks to a happy accident and implicit conversions, they are not the same at all, and should be fixed before a future compiler error happens if their declarations are touched
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicit conversion to jboolean

Changes requested by dholmes (Reviewer).

src/java.prefs/macosx/native/libprefs/MacOSXPreferencesFile.m line 698:

> 696:     CFDictionaryAddValue(parent, child, node);
> 697:     if (!beforeAdd)
> 698:         beforeAdd = CFDictionaryContainsKey(parent, child) ? JNI_TRUE : JNI_FALSE;

If you do this here you need something similar on line 695. Still say it is simpler to use Boolean internally and convert to jboolean on return expression.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13139#pullrequestreview-1366328929
PR Review Comment: https://git.openjdk.org/jdk/pull/13139#discussion_r1154068780


From aturbanov at openjdk.org  Fri Mar 31 06:47:14 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 31 Mar 2023 06:47:14 GMT
Subject: RFR: 8304912: Use OperatingSystem enum in java.desktop module
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Mar 2023 17:59:31 GMT, Roger Riggs  wrote:

> Update classes in the java.desktop module to use the jdk.internal.util.OperatingSystem enum instead of the `os.name` system property to select OS specific behaviors.

Let's at least update `sun.awt.X11.MotifColorUtilities#loadSystemColorsForCDE`
https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java#L440

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13213#issuecomment-1491395624


From shade at openjdk.org  Fri Mar 31 07:53:16 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 31 Mar 2023 07:53:16 GMT
Subject: RFR: 8304295: VM build fails with GCC 7 after JDK-8301998
In-Reply-To: 
References: 
Message-ID: <2SHDLdpt8j48h2mqJLdm0c4wPBYRX5UM5SQFTncVXq4=.38c3c2b6-4d28-47ab-b005-95f7b6d914e0@github.com>

On Thu, 30 Mar 2023 21:05:40 GMT, Joshua Cao  wrote:

> Builds successfully with GCC 7
> 
> 
> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I agree with Erik, we don't need to bother with excluding a particular compiler version here. Reading the JBS issue, I believe Kim suggested the same. This PR fixes the builds for me with GCC 7, so I am happy to approve. Someone from client-libs should ack this too, and we have @mrserb among us already :)

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13253#pullrequestreview-1366431507


From shade at openjdk.org  Fri Mar 31 07:59:16 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 31 Mar 2023 07:59:16 GMT
Subject: RFR: 8304295: VM build fails with GCC 7 after JDK-8301998
In-Reply-To: 
References: 
 
Message-ID: <4VxLVX79GonIgz3npS2347AqeZbdN-RxACOaUItUPbU=.1dd1c940-a72d-4371-9e5f-c70f606f2880@github.com>

On Thu, 30 Mar 2023 21:11:25 GMT, Joshua Cao  wrote:

>> Builds successfully with GCC 7
>> 
>> 
>> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Bot is not filling in the PR. Did I input something wrong? Edit: nevermind, its good now

I have an editorial note, though, @caojoshua: the bug says "VM build fails", but Harfbuzz is not technically part of VM. I understand it was like that before you took it. It would be better to rename the bug and this PR to "Build fails with GCC 7 after JDK-8301998", before it leaked into the permanent history of commits :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13253#issuecomment-1491472472


From djelinski at openjdk.org  Fri Mar 31 08:41:08 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 31 Mar 2023 08:41:08 GMT
Subject: RFR: 8305321: Remove unused exports in java.desktop
Message-ID: <5iIFg0d_PiJrYfcyLUbZmxZPfu9iuN5aOqxPpsWvt_I=.732a59c0-ec31-4a7b-a257-49a3f7c4f467@github.com>

Please review this patch that removes a number of unused exports from java.desktop native libraries.

In most cases I removed JNIEXPORT from methods and variables that are only used within a single shared library. Other than that:
- removed `getSunFontIDs` that was reportedly used by rasterizer; as far as I could tell, rasterizer project is dead now, but if that's incorrect I can restore that export.
- removed `colorValueID` in X11Color; that field was not used.
- removed `J2dTraceInit` from header file. That method is only used internally by `J2dTraceImpl`.

The methods `Transform_GetInfo` and `Transform_transform` are declared in GraphicsPrimitiveMgr, but are only used in TransformHelper. Let me know if I should move them to where they are used.

The method `img_makePalette`, currently located in `share/native/libawt/awt/image/cvutils/img_colors.c`, is only used by `unix/native/common/awt/X11Color.c`; it could be moved to the same directory to avoid exporting the method from libawt. The files `img_colors.[ch]` do not have any references to other files in `cvutils`.

Manually verified that the exports are no longer present after these changes. Tier1-3 and client libs tests still pass.

-------------

Commit messages:
 - Make J2dTraceInit static
 - Remove unnecessary exports

Changes: https://git.openjdk.org/jdk/pull/13261/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13261&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305321
  Stats: 42 lines in 16 files changed: 3 ins; 17 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/13261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13261/head:pull/13261

PR: https://git.openjdk.org/jdk/pull/13261


From dcherepanov at openjdk.org  Fri Mar 31 09:20:12 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Fri, 31 Mar 2023 09:20:12 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after JDK-8276849
Message-ID: 

Please review this PR which suggests to skip updateIconImages() for not yet visible windows. The displayChanged notification can be sent to a window that is in the process of initiailization and calling updateIconImages() may lead to the deadlock.

Testing: the deadlock no longer happens with this patch. The reg test for JDK-8276849 works (window icon is updated after changing DPI settings).

-------------

Commit messages:
 - skip updateIconImages for invisible windows

Changes: https://git.openjdk.org/jdk/pull/13263/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13263&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305352
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13263.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13263/head:pull/13263

PR: https://git.openjdk.org/jdk/pull/13263


From abhiscxk at openjdk.org  Fri Mar 31 12:01:10 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 31 Mar 2023 12:01:10 GMT
Subject: RFR: 7124527: [macosx] SwingSet2,
 label is not read by VoiceOver when focus is on textfield for Internalframe
 and Table demo.
Message-ID: 

In SwingSet2, few label components are not set for textfield component in InternalFrame and Table demo and due to this VoiceOver doesn't announce the label along with the textfield value. Added a fix for that and verified in SwingSet2.

Apart from that for Selection mode combobox and Autoresize combobox, VoiceOver doesn't announce the combobox panel details along with combobox current item. 

Although the bug doesn't report this but in Slider demo it is observed that VoiceOver announces the slider value and panel details together.

So, added a fix similar to slider demo for combobox in tabledemo.

-------------

Commit messages:
 - Label fix for textfield in Swingset2 demo

Changes: https://git.openjdk.org/jdk/pull/13268/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13268&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7124527
  Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13268.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13268/head:pull/13268

PR: https://git.openjdk.org/jdk/pull/13268


From abhiscxk at openjdk.org  Fri Mar 31 12:11:24 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 31 Mar 2023 12:11:24 GMT
Subject: RFR: 7124527: [macosx] SwingSet2,
 label is not read by VoiceOver when focus is on textfield for Internalframe
 and Table demo.
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Mar 2023 11:54:40 GMT, Abhishek Kumar  wrote:

> In SwingSet2, few label components are not set for textfield component in InternalFrame and Table demo and due to this VoiceOver doesn't announce the label along with the textfield value. Added a fix for that and verified in SwingSet2.
> 
> Apart from that for Selection mode combobox and Autoresize combobox, VoiceOver doesn't announce the combobox panel details along with combobox current item. 
> 
> Although the bug doesn't report this but in Slider demo it is observed that VoiceOver announces the slider value and panel details together.
> 
> So, added a fix similar to slider demo for combobox in tabledemo.

@azuev-java Please review the changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13268#issuecomment-1491831583


From erikj at openjdk.org  Fri Mar 31 13:04:15 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 31 Mar 2023 13:04:15 GMT
Subject: RFR: 8304295: VM build fails with GCC 7 after JDK-8301998
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Mar 2023 21:05:40 GMT, Joshua Cao  wrote:

> Builds successfully with GCC 7
> 
> 
> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> > The build system doesn't have a convenient way of selectively disable warnings for different compiler versions. I recommend against trying to implement that here.
> > If this library is all third-party code, does it really matter that much if we disable another warning? We aren't responsible for keeping this source warning free as we can't make changes to it to anyway.
> 
> Isnt it is possible to check the TOOLCHAIN_TYPE+TOOLCHAIN_VERSION as we did here?: [3476724](https://github.com/openjdk/jdk/commit/347672464127a5d4dd847ba2a4ca30c5ff51b32c) Or we do not set such props for gcc?

As I said, it's possible, but inconvenient, and IMO not worth it for just disabling a warning. The linked example changes an optimization flag to avoid a compiler bug. That seems like a severe enough consequence to warrant such construct in the build. We want to avoid having a large amount of compiler version checks in the makefiles. In make we can only easily compare versions for equality and not ranges. 

That said, it may be worth adding a comment that this warning has only been observed with GCC 7. That will help in the future when someone tries to remove disabled warnings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13253#issuecomment-1491890387


From abhiscxk at openjdk.org  Fri Mar 31 15:35:59 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 31 Mar 2023 15:35:59 GMT
Subject: RFR: 8283404: [macos] a11y : Screen magnifier does not show JMenu name
Message-ID: 

It seems that the accessibility role returned by the MenuAccessibility class is not correct for top level menu.

Added a condition check to return the accessibility role as `NSAccessibilityMenuBarItemRole` in stead of `NSAccessibilityMenuRole` for top level menu whose parent is `menubar`. 

The solution works correctly for screen magnifier as well as voice over. 

A manual test case is added to verify the fix.

Note: Tried implementing few a11y methods to fix but for top level menu with `NSAccessibilityMenuRole` doesn't return the a11y label.

-------------

Commit messages:
 - JMenu A11Y Screen Magnifier Fix

Changes: https://git.openjdk.org/jdk/pull/13271/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13271&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283404
  Stats: 114 lines in 2 files changed: 111 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13271/head:pull/13271

PR: https://git.openjdk.org/jdk/pull/13271


From serb at openjdk.org  Fri Mar 31 16:26:15 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 31 Mar 2023 16:26:15 GMT
Subject: RFR: 8304295: VM build fails with GCC 7 after JDK-8301998
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Mar 2023 13:00:08 GMT, Erik Joelsson  wrote:

> That said, it may be worth adding a comment that this warning has only been observed with GCC 7. That will help in the future when someone tries to remove disabled warnings.

Then the comment is better than nothing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13253#issuecomment-1492230988


From serb at openjdk.org  Fri Mar 31 16:37:19 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 31 Mar 2023 16:37:19 GMT
Subject: RFR: 8283404: [macos] a11y : Screen magnifier does not show JMenu
 name
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Mar 2023 15:27:50 GMT, Abhishek Kumar  wrote:

> It seems that the accessibility role returned by the MenuAccessibility class is not correct for top level menu.
> 
> Added a condition check to return the accessibility role as `NSAccessibilityMenuBarItemRole` in stead of `NSAccessibilityMenuRole` for top level menu whose parent is `menubar`. 
> 
> The solution works correctly for screen magnifier as well as voice over. 
> 
> A manual test case is added to verify the fix.
> 
> Note: Tried implementing few a11y methods to fix but for top level menu with `NSAccessibilityMenuRole` doesn't return the a11y label.

test/jdk/javax/accessibility/JMenu/TestJMenuScreenMagnifier.java line 48:

> 46:                 "System Preference -> Accessibility -> Zoom -> " +
> 47:                 "Select ( Enable Hover Text) \n\n" +
> 48:             "2) Run with -Djavax.accessibility.screen_magnifier_present=true" +

What the user should "Run" at this step?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13271#discussion_r1154683797


From abhiscxk at openjdk.org  Fri Mar 31 17:00:16 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 31 Mar 2023 17:00:16 GMT
Subject: RFR: 8283404: [macos] a11y : Screen magnifier does not show JMenu
 name
In-Reply-To: 
References: 
 
Message-ID: <6qu0EJAhjmTuTMmJp9FlCmr_WeUxsaTXRcXR6dOsvBk=.c486aeca-584f-4848-a676-cd0187d89e5f@github.com>

On Fri, 31 Mar 2023 16:34:53 GMT, Sergey Bylokhov  wrote:

>> It seems that the accessibility role returned by the MenuAccessibility class is not correct for top level menu.
>> 
>> Added a condition check to return the accessibility role as `NSAccessibilityMenuBarItemRole` in stead of `NSAccessibilityMenuRole` for top level menu whose parent is `menubar`. 
>> 
>> The solution works correctly for screen magnifier as well as voice over. 
>> 
>> A manual test case is added to verify the fix.
>> 
>> Note: Tried implementing few a11y methods to fix but for top level menu with `NSAccessibilityMenuRole` doesn't return the a11y label.
>
> test/jdk/javax/accessibility/JMenu/TestJMenuScreenMagnifier.java line 48:
> 
>> 46:                 "System Preference -> Accessibility -> Zoom -> " +
>> 47:                 "Select ( Enable Hover Text) \n\n" +
>> 48:             "2) Run with -Djavax.accessibility.screen_magnifier_present=true" +
> 
> What the user should "Run" at this step?

This step is not required. Copy+paste mistake from JBS description.
I will update the test instruction.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13271#discussion_r1154702881


From abhiscxk at openjdk.org  Fri Mar 31 17:08:19 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 31 Mar 2023 17:08:19 GMT
Subject: RFR: 8283404: [macos] a11y : Screen magnifier does not show JMenu
 name [v2]
In-Reply-To: 
References: 
Message-ID: 

> It seems that the accessibility role returned by the MenuAccessibility class is not correct for top level menu.
> 
> Added a condition check to return the accessibility role as `NSAccessibilityMenuBarItemRole` in stead of `NSAccessibilityMenuRole` for top level menu whose parent is `menubar`. 
> 
> The solution works correctly for screen magnifier as well as voice over. 
> 
> A manual test case is added to verify the fix.
> 
> Note: Tried implementing few a11y methods to fix but for top level menu with `NSAccessibilityMenuRole` doesn't return the a11y label.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Test instruction update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13271/files
  - new: https://git.openjdk.org/jdk/pull/13271/files/3c668b46..5a4972aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13271&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13271&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13271/head:pull/13271

PR: https://git.openjdk.org/jdk/pull/13271


From abhiscxk at openjdk.org  Fri Mar 31 17:08:22 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 31 Mar 2023 17:08:22 GMT
Subject: RFR: 8283404: [macos] a11y : Screen magnifier does not show JMenu
 name [v2]
In-Reply-To: <6qu0EJAhjmTuTMmJp9FlCmr_WeUxsaTXRcXR6dOsvBk=.c486aeca-584f-4848-a676-cd0187d89e5f@github.com>
References: 
 
 <6qu0EJAhjmTuTMmJp9FlCmr_WeUxsaTXRcXR6dOsvBk=.c486aeca-584f-4848-a676-cd0187d89e5f@github.com>
Message-ID: 

On Fri, 31 Mar 2023 16:57:26 GMT, Abhishek Kumar  wrote:

>> test/jdk/javax/accessibility/JMenu/TestJMenuScreenMagnifier.java line 48:
>> 
>>> 46:                 "System Preference -> Accessibility -> Zoom -> " +
>>> 47:                 "Select ( Enable Hover Text) \n\n" +
>>> 48:             "2) Run with -Djavax.accessibility.screen_magnifier_present=true" +
>> 
>> What the user should "Run" at this step?
>
> This step is not required. Copy+paste mistake from JBS description.
> I will update the test instruction.

> What the user should "Run" at this step?

Updated the test instruction.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13271#discussion_r1154707846


From prr at openjdk.org  Fri Mar 31 18:32:16 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 31 Mar 2023 18:32:16 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Mar 2023 09:11:20 GMT, Dmitry Cherepanov  wrote:

> Please review this PR which suggests to skip updateIconImages() for not yet visible windows. The displayChanged notification can be sent to a window that is in the process of initiailization and calling updateIconImages() may lead to the deadlock.
> 
> Testing: the deadlock no longer happens with this patch. The reg test for JDK-8276849 works (window icon is updated after changing DPI settings).

No objections to a safe fix for this, but the app is creating and - more to the point - showing (setVisible) the AWT window on the main thread.
Even for AWT (non-swing) apps, it is recommended to do it on the EDT to avoid threading issues - such as this.
Lots of apps do use the main thread, and have no issues but that's not guaranteed.

I can't find where this is documented .. I do remember it was quite a number of years ago that this advice was first offered. 

I suppose you could not create a reliable test for this ? Please add noreg-hard to the bug.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13263#pullrequestreview-1367407739


From serb at openjdk.org  Fri Mar 31 18:55:16 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 31 Mar 2023 18:55:16 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: 
References: 
Message-ID: <6Rp2TSV6rWpVZT4DXAQb6cY7iz5D_0iFFHjTr-1X8tY=.91fdc998-26ad-494f-b8b9-12ece506e3f6@github.com>

On Fri, 31 Mar 2023 09:11:20 GMT, Dmitry Cherepanov  wrote:

> Please review this PR which suggests to skip updateIconImages() for not yet visible windows. The displayChanged notification can be sent to a window that is in the process of initiailization and calling updateIconImages() may lead to the deadlock.
> 
> Testing: the deadlock no longer happens with this patch. The reg test for JDK-8276849 works (window icon is updated after changing DPI settings).

src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java line 605:

> 603:         if (((Window)target).isVisible()) {
> 604:             updateIconImages();
> 605:         }

Will we call "updateIconImages" when later we show the window or an update of the icons will be missed if the notification come when the window is invisible?

Are you sure that it is not possible to trigger the next "trace" in the application w/o using "updateIconImages"?

	at sun.java2d.loops.GraphicsPrimitiveMgr.initIDs(java.desktop at 21-ea/Native Method)
	- waiting on the Class initialization monitor for sun.java2d.loops.Blit
	at sun.java2d.loops.GraphicsPrimitiveMgr.(java.desktop at 21-ea/GraphicsPrimitiveMgr.java:56)
	at sun.java2d.loops.DrawLine.locate(java.desktop at 21-ea/DrawLine.java:51)
	at sun.java2d.SurfaceData.makeRenderLoops(java.desktop at 21-ea/SurfaceData.java:884)
	at sun.awt.image.BufImgSurfaceData.getSolidLoops(java.desktop at 21-ea/BufImgSurfaceData.java:412)
	- locked <0x00000000c3fdd920> (a java.lang.Class for sun.awt.image.BufImgSurfaceData)
	at sun.awt.image.BufImgSurfaceData.initSolidLoops(java.desktop at 21-ea/BufImgSurfaceData.java:397)
	at sun.awt.image.BufImgSurfaceData.createData(java.desktop at 21-ea/BufImgSurfaceData.java:256)
	at sun.awt.image.BufImgSurfaceData.createData(java.desktop at 21-ea/BufImgSurfaceData.java:74)
	at sun.awt.image.BufImgSurfaceManager.(java.desktop at 21-ea/BufImgSurfaceManager.java:55)
	at sun.awt.image.SurfaceManager.getManager(java.desktop at 21-ea/SurfaceManager.java:79)
	at sun.java2d.SurfaceData.getPrimarySurfaceData(java.desktop at 21-ea/SurfaceData.java:275)
	at sun.java2d.SunGraphicsEnvironment.createGraphics(java.desktop at 21-ea/SunGraphicsEnvironment.java:132)
	at java.awt.image.BufferedImage.createGraphics(java.desktop at 21-ea/BufferedImage.java:1183)
	at sun.awt.SunToolkit.getScaledIconImage(java.desktop at 21-ea/SunToolkit.java:1032)
	at sun.awt.SunToolkit.getScaledIconData(java.desktop at 21-ea/SunToolkit.java:1046)
	at sun.awt.windows.WWindowPeer.updateIconImages(java.desktop at 21-ea/WWindowPeer.java:468)
	at sun.awt.windows.WWindowPeer.updateGC(java.desktop at 21-ea/WWindowPeer.java:603)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13263#discussion_r1154794930


From serb at openjdk.org  Fri Mar 31 19:03:19 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 31 Mar 2023 19:03:19 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: <6Rp2TSV6rWpVZT4DXAQb6cY7iz5D_0iFFHjTr-1X8tY=.91fdc998-26ad-494f-b8b9-12ece506e3f6@github.com>
References: 
 <6Rp2TSV6rWpVZT4DXAQb6cY7iz5D_0iFFHjTr-1X8tY=.91fdc998-26ad-494f-b8b9-12ece506e3f6@github.com>
Message-ID: 

On Fri, 31 Mar 2023 18:52:08 GMT, Sergey Bylokhov  wrote:

>> Please review this PR which suggests to skip updateIconImages() for not yet visible windows. The displayChanged notification can be sent to a window that is in the process of initiailization and calling updateIconImages() may lead to the deadlock.
>> 
>> Testing: the deadlock no longer happens with this patch. The reg test for JDK-8276849 works (window icon is updated after changing DPI settings).
>
> src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java line 605:
> 
>> 603:         if (((Window)target).isVisible()) {
>> 604:             updateIconImages();
>> 605:         }
> 
> Will we call "updateIconImages" when later we show the window or an update of the icons will be missed if the notification come when the window is invisible?
> 
> Are you sure that it is not possible to trigger the next "trace" in the application w/o using "updateIconImages"?
> 
> 	at sun.java2d.loops.GraphicsPrimitiveMgr.initIDs(java.desktop at 21-ea/Native Method)
> 	- waiting on the Class initialization monitor for sun.java2d.loops.Blit
> 	at sun.java2d.loops.GraphicsPrimitiveMgr.(java.desktop at 21-ea/GraphicsPrimitiveMgr.java:56)
> 	at sun.java2d.loops.DrawLine.locate(java.desktop at 21-ea/DrawLine.java:51)
> 	at sun.java2d.SurfaceData.makeRenderLoops(java.desktop at 21-ea/SurfaceData.java:884)
> 	at sun.awt.image.BufImgSurfaceData.getSolidLoops(java.desktop at 21-ea/BufImgSurfaceData.java:412)
> 	- locked <0x00000000c3fdd920> (a java.lang.Class for sun.awt.image.BufImgSurfaceData)
> 	at sun.awt.image.BufImgSurfaceData.initSolidLoops(java.desktop at 21-ea/BufImgSurfaceData.java:397)
> 	at sun.awt.image.BufImgSurfaceData.createData(java.desktop at 21-ea/BufImgSurfaceData.java:256)
> 	at sun.awt.image.BufImgSurfaceData.createData(java.desktop at 21-ea/BufImgSurfaceData.java:74)
> 	at sun.awt.image.BufImgSurfaceManager.(java.desktop at 21-ea/BufImgSurfaceManager.java:55)
> 	at sun.awt.image.SurfaceManager.getManager(java.desktop at 21-ea/SurfaceManager.java:79)
> 	at sun.java2d.SurfaceData.getPrimarySurfaceData(java.desktop at 21-ea/SurfaceData.java:275)
> 	at sun.java2d.SunGraphicsEnvironment.createGraphics(java.desktop at 21-ea/SunGraphicsEnvironment.java:132)
> 	at java.awt.image.BufferedImage.createGraphics(java.desktop at 21-ea/BufferedImage.java:1183)
> 	at sun.awt.SunToolkit.getScaledIconImage(java.desktop at 21-ea/SunToolkit.java:1032)
> 	at sun.awt.SunToolkit.getScaledIconData(java.desktop at 21-ea/SunToolkit.java:1046)
> 	at sun.awt.windows.WWindowPeer.updateIconImages(java.desktop at 21-ea/WWindowPeer.java:468)
> 	at sun.awt.windows.WWindowPeer.updateGC(java.desktop at 21-ea/WWindowPeer.java:603)

It seems that the root cause is a cyclic dependency between GraphicsPrimitiveMgr and Blit during static initialization

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13263#discussion_r1154801101


From prr at openjdk.org  Fri Mar 31 19:06:16 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 31 Mar 2023 19:06:16 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Mar 2023 09:11:20 GMT, Dmitry Cherepanov  wrote:

> Please review this PR which suggests to skip updateIconImages() for not yet visible windows. The displayChanged notification can be sent to a window that is in the process of initiailization and calling updateIconImages() may lead to the deadlock.
> 
> Testing: the deadlock no longer happens with this patch. The reg test for JDK-8276849 works (window icon is updated after changing DPI settings).

that's a good point. If the window is created and later iconifiied (for example) and then this notification comes in, will it be missed ?

-------------

Changes requested by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13263#pullrequestreview-1367452061


From prr at openjdk.org  Fri Mar 31 19:10:14 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 31 Mar 2023 19:10:14 GMT
Subject: RFR: 8305352: updateIconImages may lead to deadlock after
 JDK-8276849
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Mar 2023 09:11:20 GMT, Dmitry Cherepanov  wrote:

> Please review this PR which suggests to skip updateIconImages() for not yet visible windows. The displayChanged notification can be sent to a window that is in the process of initiailization and calling updateIconImages() may lead to the deadlock.
> 
> Testing: the deadlock no longer happens with this patch. The reg test for JDK-8276849 works (window icon is updated after changing DPI settings).

> It seems that the root cause is a cyclic dependency between GraphicsPrimitiveMgr and Blit during static initialization

Yes, and there was a bug on this a long time ago, but for bureaucratic reasons it got closed.
It ought to be re-opened : https://bugs.openjdk.org/browse/JDK-6995195

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13263#issuecomment-1492462572


From serb at openjdk.org  Fri Mar 31 20:05:17 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 31 Mar 2023 20:05:17 GMT
Subject: RFR: 8283404: [macos] a11y : Screen magnifier does not show JMenu
 name [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Mar 2023 17:08:19 GMT, Abhishek Kumar  wrote:

>> It seems that the accessibility role returned by the MenuAccessibility class is not correct for top level menu.
>> 
>> Added a condition check to return the accessibility role as `NSAccessibilityMenuBarItemRole` in stead of `NSAccessibilityMenuRole` for top level menu whose parent is `menubar`. 
>> 
>> The solution works correctly for screen magnifier as well as voice over. 
>> 
>> A manual test case is added to verify the fix.
>> 
>> Note: Tried implementing few a11y methods to fix but for top level menu with `NSAccessibilityMenuRole` doesn't return the a11y label.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test instruction update

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13271#pullrequestreview-1367526608


From duke at openjdk.org  Fri Mar 31 21:27:09 2023
From: duke at openjdk.org (Joshua Cao)
Date: Fri, 31 Mar 2023 21:27:09 GMT
Subject: RFR: 8304295: harfbuzz build fails with GCC 7 after JDK-8301998
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Mar 2023 13:00:08 GMT, Erik Joelsson  wrote:

>> Builds successfully with GCC 7
>> 
>> 
>> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>> > The build system doesn't have a convenient way of selectively disable warnings for different compiler versions. I recommend against trying to implement that here.
>> > If this library is all third-party code, does it really matter that much if we disable another warning? We aren't responsible for keeping this source warning free as we can't make changes to it to anyway.
>> 
>> Isnt it is possible to check the TOOLCHAIN_TYPE+TOOLCHAIN_VERSION as we did here?: [3476724](https://github.com/openjdk/jdk/commit/347672464127a5d4dd847ba2a4ca30c5ff51b32c) Or we do not set such props for gcc?
> 
> As I said, it's possible, but inconvenient, and IMO not worth it for just disabling a warning. The linked example changes an optimization flag to avoid a compiler bug. That seems like a severe enough consequence to warrant such construct in the build. We want to avoid having a large amount of compiler version checks in the makefiles. In make we can only easily compare versions for equality and not ranges. 
> 
> That said, it may be worth adding a comment that this warning has only been observed with GCC 7. That will help in the future when someone tries to remove disabled warnings.

Added a comment as suggested by @erikj79 

I incorrectly used the `/summary` command. Turns out the bot is smart enough to update from the updated JBS isssue, and the summary command does not do what I thought. Let me try to fix it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13253#issuecomment-1492621972


From duke at openjdk.org  Fri Mar 31 21:27:08 2023
From: duke at openjdk.org (Joshua Cao)
Date: Fri, 31 Mar 2023 21:27:08 GMT
Subject: RFR: 8304295: harfbuzz build fails with GCC 7 after JDK-8301998
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Builds successfully with GCC 7
> 
> 
> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:

  Add a comment clarifying noexcept-type is only required for GCC 7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13253/files
  - new: https://git.openjdk.org/jdk/pull/13253/files/51e9a59f..d2218410

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13253&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13253&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13253/head:pull/13253

PR: https://git.openjdk.org/jdk/pull/13253


From jlu at openjdk.org  Fri Mar 31 21:41:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 31 Mar 2023 21:41:17 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
Message-ID: 

On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu  wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close streams when finished loading into props

Something thing to consider is that Intellj defaults .properties files to ISO 8859-1. 

https://www.jetbrains.com/help/idea/properties-files.html#encoding

So users of Intellj / (other IDEs that default to ISO 8859-1 for .properties files) will need to change the default encoding to utf-8 for such files. Or ideally, the respective IDEs can change their default encoding for .properties files if this change is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492640306


From erikj at openjdk.org  Fri Mar 31 22:00:20 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 31 Mar 2023 22:00:20 GMT
Subject: RFR: 8304295: harfbuzz build fails with GCC 7 after JDK-8301998
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Mar 2023 21:27:08 GMT, Joshua Cao  wrote:

>> Builds successfully with GCC 7
>> 
>> 
>> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment clarifying noexcept-type is only required for GCC 7

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13253#pullrequestreview-1367668141


From serb at openjdk.org  Fri Mar 31 22:04:14 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 31 Mar 2023 22:04:14 GMT
Subject: RFR: 7124527: [macosx] SwingSet2,
 label is not read by VoiceOver when focus is on textfield for Internalframe
 and Table demo.
In-Reply-To: 
References: 
Message-ID: <6qLFJWs35roSQMpztdOeM8Rsg01g6toVYHDyGMKoHEA=.531db65a-9389-4185-a6c7-4c33d9584000@github.com>

On Fri, 31 Mar 2023 11:54:40 GMT, Abhishek Kumar  wrote:

> In SwingSet2, few label components are not set for textfield component in InternalFrame and Table demo and due to this VoiceOver doesn't announce the label along with the textfield value. Added a fix for that and verified in SwingSet2.
> 
> Apart from that for Selection mode combobox and Autoresize combobox, VoiceOver doesn't announce the combobox panel details along with combobox current item. 
> 
> Although the bug doesn't report this but in Slider demo it is observed that VoiceOver announces the slider value and panel details together.
> 
> So, added a fix similar to slider demo for combobox in tabledemo.

Looks fine, please update the dates in the copyright block.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13268#issuecomment-1492662752


From serb at openjdk.org  Fri Mar 31 22:05:19 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 31 Mar 2023 22:05:19 GMT
Subject: RFR: 8304295: harfbuzz build fails with GCC 7 after JDK-8301998
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <744LuJe1SLeX27Hzpz0lov7GyJX8zyG1OEUbMh7d8n8=.4de386cd-95bd-459c-b93e-26b4b759e278@github.com>

On Fri, 31 Mar 2023 21:27:08 GMT, Joshua Cao  wrote:

>> Builds successfully with GCC 7
>> 
>> 
>> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment clarifying noexcept-type is only required for GCC 7

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13253#pullrequestreview-1367672319


From naoto at openjdk.org  Fri Mar 31 22:48:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 22:48:29 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
Message-ID: 

On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu  wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close streams when finished loading into props

Hmm, I just wonder why they are sticking to ISO-8859-1 as the default. I know j.u.Properties defaults to 8859-1, but PropertyResourceBundle, which is their primary use defaults to UTF-8 since JDK9 (https://openjdk.org/jeps/226)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492682703


From martin.pernollet at protonmail.com  Wed Mar 15 08:37:44 2023
From: martin.pernollet at protonmail.com (Martin Pernollet)
Date: Wed, 15 Mar 2023 08:37:44 -0000
Subject: JVM hang with Swing and macOS
In-Reply-To: 
References: 
 
Message-ID: 

Hi Sergey,

We access OpenGL through native bindings generated by JExtract, from project Panama. These bindings are packaged as a library visible here (https://gitlab.com/jzy3d/panama-gl).

The -XstartOnFirstThread option is needed by OpenGL on macOS as OpenGL invocation MUST be performed from macOS main thread. 

Not using this option on macOS lead to an error

java[92246:2751169] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: NSWindow drag regions should only be invalidated on the Main Thread!

Using this option on macOS lead to a freeze in LockSupport.park() (see the attached image for the complete call stack)

JOGL has a smart way of solving this with a class allowing to push Runnables to macOS main thread (https://github.com/jzy3d/jogl/blob/ecf6e499d3b582d651a28693c871ca14d6e8c991/src/nativewindow/classes/jogamp/nativewindow/macosx/OSXUtil.java#L305) based on ObjectiveC code from Apple's AppKit framework (https://github.com/jzy3d/jogl/blob/ecf6e499d3b582d651a28693c871ca14d6e8c991/src/nativewindow/native/macosx/OSXmisc.m#L1167). 
This allows running on Swing without having to use the -XstartOnFirstThread.

However JOGL has several issues, one of these being that it freezes JVM>=19 as soon as it appears in the classpath (for other reasons than the one discussed above). 

This issue is a real pain for anyone publishing applications involving OpenGL in Swing - whatever the OpenGL binding framework. Not solving the issue would make project Panama unusable for computer graphics.

Regards,

Martin

------- Original Message -------
Le mardi 14 mars 2023 ? 19:18, Sergey Bylokhov  a ?crit?:


> On 3/14/23 10:38, Martin Pernollet wrote:
> 
> > I work on projects involving OpenGL in Swing.
> > 
> > We are hitting anold JDK issue that prevent to properly run OpenGL on macOS+Swing
> > https://bugs.openjdk.org/browse/JDK-8289573. > You may know that Swing hangs on macOS when using -XstartOnFirstThread option. However, this option
> > is mandatory for native OpenGL to work on macOS (the reason is that OpenGL is single threaded and
> > that macOS impose to have all calls to OpenGL issued on the main macOS thread).
> 
> 
> Can you please add some details on what issue did you hit. That option is not needed when the app
> uses the built-in AWT/Swing, do your application use some external libraries like JOGL, SWT or JavaFX?
> 
> --
> Best regards, Sergey.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 161934 bytes
Desc: not available
URL: 

