Integrated: 8263420: Incorrect function name in NSAccessibilityStaticText native peer implementation
On Thu, 11 Mar 2021 07:57:23 GMT, Pankaj Bansal wrote: > The implementation of NSAccessibilityStaticText protocol > (https://developer.apple.com/documentation/appkit/nsaccessibilitystatictext) > has an incorrect function name which results in the function not being called > by Voice Over. The Voice Over output is not getting affected by this bug as > the accessibilityValue function returns the correct label value and Voice > Over output is correct in all the Label test cases which were tested while > implementing the NSAccessibilityStaticText, like few cases in this in > following demo. This is the reason that this issue was not caught in testing. > (https://docs.oracle.com/javase/tutorial/uiswing/examples/components/LabelDemoProject/src/components/LabelDemo.java). > > Though it does not seem to cause any issue as of now and I still could not > find a testcase where it is causing any difference in Voice Over output, this > may create problem in future. The functions is getting called by Voice Over > after this fix, so this should be fixed. This pull request has now been integrated. Changeset: d896246a Author:Pankaj Bansal URL: https://git.openjdk.java.net/jdk/commit/d896246a Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8263420: Incorrect function name in NSAccessibilityStaticText native peer implementation Reviewed-by: kizune - PR: https://git.openjdk.java.net/jdk/pull/2933
Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM
On 16/03/2021 11:58 am, Sergey Bylokhov wrote: On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen wrote: This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS. As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu. The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set. This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8076264, and the fix looks fine. Both issues involve a problem trying to use the canonical name, but I'd consider both fixes deficient when an alternative name could be used. But this isn't my code so ... David - PR: https://git.openjdk.java.net/jdk/pull/2999
Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM
On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen wrote: > This patch ensure launcher won't crash JVM for the new static Methods from > local/anonymous class on MacOS. > > As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug > when the launcher trying to grab class name to be displayed as the > Application name on the menu. > > The fix is to not setting name, test shows that GUI java application shows > 'bin' as the application name. It's possible for us to set the name to > something more friendly, for example, "Java", but I am not sure that should > be launcher's responsibility to choose such a default name. It seems to me > the consumer of the JAVA_MAIN_CLASS_%d environment variable should be > responsible to pick such name in case the environment variable is not set. test/jdk/tools/launcher/8261785/CrashTheJVM.java line 1: > 1: import java.io.IOException; Copyright? test/jdk/tools/launcher/8261785/Test8261785.java line 5: > 3: * COPYRIGHT NOTICES OR THIS FILE HEADER. > 4: * > 5: * This code is free software; you can redistribute it and/or modify it > under the terms of the GNU Looks like formatting much wider than usual - PR: https://git.openjdk.java.net/jdk/pull/2999
Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM
On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen wrote: > This patch ensure launcher won't crash JVM for the new static Methods from > local/anonymous class on MacOS. > > As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug > when the launcher trying to grab class name to be displayed as the > Application name on the menu. > > The fix is to not setting name, test shows that GUI java application shows > 'bin' as the application name. It's possible for us to set the name to > something more friendly, for example, "Java", but I am not sure that should > be launcher's responsibility to choose such a default name. It seems to me > the consumer of the JAVA_MAIN_CLASS_%d environment variable should be > responsible to pick such name in case the environment variable is not set. This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8076264, and the fix looks fine. - PR: https://git.openjdk.java.net/jdk/pull/2999
RFR: 8261352: Create implementation for component peer for all the components who should be ignored in a11y interactions
Initial implementation Moved the CAccessibility ignore list initialization to the new code Some cleanup Expose a new API - isAccessibilityElement instead of deprecated accessibilityIsIgnored - Commit messages: - 8261352: Create implementation for component peer for all the components who should be ignored in a11y interactions Changes: https://git.openjdk.java.net/jdk/pull/3015/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3015=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261352 Stats: 140 lines in 5 files changed: 101 ins; 36 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3015.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3015/head:pull/3015 PR: https://git.openjdk.java.net/jdk/pull/3015
Integrated: 8263530: sun.awt.X11.ListHelper.removeAll() should use clear()
On Fri, 12 Mar 2021 15:44:39 GMT, Aleksey Shipilev wrote:
> SonarCloud reports:
> Remove or correct this "removeAll" call.
>
> void removeAll() {
> items.removeAll(items); // <--- here
> updateScrollbars();
> }
>
> Calling `removeAll()` with the same collection risks concurrent modification
> exceptions. `clear()` would be correct and more efficient.
This pull request has now been integrated.
Changeset: 7b4aefe9
Author:Aleksey Shipilev
URL: https://git.openjdk.java.net/jdk/commit/7b4aefe9
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
8263530: sun.awt.X11.ListHelper.removeAll() should use clear()
Reviewed-by: serb, kizune
-
PR: https://git.openjdk.java.net/jdk/pull/2974
Integrated: 8263490: [macos] Crash occurs on JPasswordField with activated InputMethod
On Fri, 12 Mar 2021 08:16:09 GMT, Toshio Nakamura wrote: > Hi, > Please review the fix for the issue of JPasswordField and activated > InputMethod on macOS. > I don't think this condition is usual, but I'd like to avoid crash. > > It needs two additional checks in "AWTView > attributedSubstringForProposedRange:actualRange". > > Tested test/jdk/java/awt on macOS Catalina and BigSur (both headful), and no > regression was occurred. This pull request has now been integrated. Changeset: 32c7fcc6 Author:Toshio Nakamura Committer: Dmitry Markov URL: https://git.openjdk.java.net/jdk/commit/32c7fcc6 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8263490: [macos] Crash occurs on JPasswordField with activated InputMethod Reviewed-by: dmarkov, serb, kizune - PR: https://git.openjdk.java.net/jdk/pull/2959
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v10]
On Fri, 12 Mar 2021 00:36:34 GMT, Sergey Bylokhov wrote: >> I fixed some conversion logic within JDK-8256331. > > OK, just to confirm. I wrote that text for OGL because it was the fastest way > to transfer+convert the data from the video card to the memory. And as far as > I understand the metal has the same limitation? It is not possible to convert > it to some non-ARGB/Pre format on the fly while transferring the pixles? If we're talking about metal blit operation, the answer is No. Also, it looks like we still need a blit operation from video memory even if we use compute shader. - PR: https://git.openjdk.java.net/jdk/pull/2403
Integrated: 8260931: Implement JEP 382: New macOS Rendering Pipeline
On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas wrote: > **Description :** > This is the implementation of [JEP 382 : New macOS Rendering > Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) > It implements a Java 2D internal rendering pipeline for macOS using the Apple > Metal API. > The entire work on this was done under [OpenJDK Project - > Lanai](http://openjdk.java.net/projects/lanai/) > > We iterated through several Early Access (EA) builds and have reached a stage > where it is ready to be integrated to openjdk/jdk. The latest EA build is > available at - https://jdk.java.net/lanai/ > > A new option -Dsun.java2d.metal=true | True needs to be used to use this > pipeline. > > **Testing :** > This implementation has been tested with the tests present at - [Test Plan > for JEP 382: New macOS Rendering > Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396) > > **Note to reviewers :** > 1) Default rendering pipeline on macOS has not been changed by this PR. > OpenGL still stays as the default rendering pipeline and Metal rendering > pipeline is optional to choose. > > 2) To apply and test this PR - > To enable the metal pipeline you must specify on command line > -Dsun.java2d.metal=true (No message will be printed in this case) or > -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is > enabled gets printed) > > 3) Review comments (including some preliminary informal review comments) are > tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598 This pull request has now been integrated. Changeset: 8afec70c Author:Ajit Ghaisas URL: https://git.openjdk.java.net/jdk/commit/8afec70c Stats: 17612 lines in 87 files changed: 17573 ins; 2 del; 37 mod 8260931: Implement JEP 382: New macOS Rendering Pipeline Co-authored-by: Jayathirth D V Co-authored-by: Alexey Ushakov Co-authored-by: Artem Bochkarev Co-authored-by: Prasanta Sadhukhan Co-authored-by: Denis Konoplev Co-authored-by: Phil Race Co-authored-by: Kevin Rushforth Co-authored-by: Magnus Ihse Bursie Co-authored-by: Ajit Ghaisas Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, psadhukhan, serb - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8263530: sun.awt.X11.ListHelper.removeAll() should use clear() [v2]
> SonarCloud reports:
> Remove or correct this "removeAll" call.
>
> void removeAll() {
> items.removeAll(items); // <--- here
> updateScrollbars();
> }
>
> Calling `removeAll()` with the same collection risks concurrent modification
> exceptions. `clear()` would be correct and more efficient.
Aleksey Shipilev has updated the pull request incrementally with one additional
commit since the last revision:
Update copyright
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/2974/files
- new: https://git.openjdk.java.net/jdk/pull/2974/files/7dc5ab53..d1565744
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk=2974=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk=2974=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.java.net/jdk/pull/2974.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/2974/head:pull/2974
PR: https://git.openjdk.java.net/jdk/pull/2974
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v13]
On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas wrote: >> **Description :** >> This is the implementation of [JEP 382 : New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) >> It implements a Java 2D internal rendering pipeline for macOS using the >> Apple Metal API. >> The entire work on this was done under [OpenJDK Project - >> Lanai](http://openjdk.java.net/projects/lanai/) >> >> We iterated through several Early Access (EA) builds and have reached a >> stage where it is ready to be integrated to openjdk/jdk. The latest EA build >> is available at - https://jdk.java.net/lanai/ >> >> A new option -Dsun.java2d.metal=true | True needs to be used to use this >> pipeline. >> >> **Testing :** >> This implementation has been tested with the tests present at - [Test Plan >> for JEP 382: New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396) >> >> **Note to reviewers :** >> 1) Default rendering pipeline on macOS has not been changed by this PR. >> OpenGL still stays as the default rendering pipeline and Metal rendering >> pipeline is optional to choose. >> >> 2) To apply and test this PR - >> To enable the metal pipeline you must specify on command line >> -Dsun.java2d.metal=true (No message will be printed in this case) or >> -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is >> enabled gets printed) >> >> 3) Review comments (including some preliminary informal review comments) are >> tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598 > > Ajit Ghaisas has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 47 additional > commits since the last revision: > > - Lanai PR#214 - 8263324 - avu > - Merge branch 'master' into 8260931_lanai_JEP_branch > - Lanai PR#213 - 8263325 - avu > - Lanai PR#212 - 8259825 - aghaisas > - Lanai PR#211 - 8262882 - aghaisas > - Merge branch 'master' into 8260931_lanai_JEP_branch > - Lanai PR#210 - 8263159 - jdv > - Lanai PR#209 - 8262936 - jdv > - Lanai PR#208 - 8262928 - jdv > - Lanai PR#207 - 8262750 - jdv > - ... and 37 more: > https://git.openjdk.java.net/jdk/compare/74f2d574...369c3d21 Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2403
