Integrated: 8332403: Anachronistic reference to Netscape Communicator in Swing API docs
On Fri, 17 May 2024 03:37:21 GMT, Prasanta Sadhukhan wrote: > Inadvertent mention of Netscape in Javadoc is removed.. This pull request has now been integrated. Changeset: b92bd671 Author:Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/b92bd671835c37cff58e2cdcecd0fe4277557d7f Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8332403: Anachronistic reference to Netscape Communicator in Swing API docs Reviewed-by: abhiscxk, aivanov, prr - PR: https://git.openjdk.org/jdk/pull/19276
Re: RFR: 8332403: Anachronistic reference to Netscape Communicator in Swing API docs [v3]
> Inadvertent mention of Netscape in Javadoc is removed.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: e.g typo - Changes: - all: https://git.openjdk.org/jdk/pull/19276/files - new: https://git.openjdk.org/jdk/pull/19276/files/fed045f8..6c06e49d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19276&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19276&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19276.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19276/head:pull/19276 PR: https://git.openjdk.org/jdk/pull/19276
Re: RFR: 8332403: Anachronistic reference to Netscape Communicator in Swing API docs [v2]
On Fri, 17 May 2024 14:04:28 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - doc clarity >> - doc clarity > > src/java.desktop/share/classes/javax/swing/CellEditor.java line 91: > >> 89: * cell should be selected. However, it is useful to return false to >> 90: * keep the selection from changing for some types of edits, >> 91: * eg. in a table that contains a column of check boxes, the user >> might > > Most guides recommend to spell _“e.g.”_ with the period after each letter, > see [an article at > Grammarly](https://www.grammarly.com/blog/know-your-latin-i-e-vs-e-g/). > Alternatively, it could be replaced with _“for example”_. yes, it should be "e.g.", - PR Review Comment: https://git.openjdk.org/jdk/pull/19276#discussion_r1605395049
Re: RFR: 8332403: Anachronistic reference to Netscape Communicator in Swing API docs [v2]
On Fri, 17 May 2024 12:16:15 GMT, Prasanta Sadhukhan wrote: >> Inadvertent mention of Netscape in Javadoc is removed.. > > Prasanta Sadhukhan has updated the pull request incrementally with two > additional commits since the last revision: > > - doc clarity > - doc clarity Marked as reviewed by prr (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/19276#pullrequestreview-2064117761
Re: RFR: 8332403: Anachronistic reference to Netscape Communicator in Swing API docs [v2]
On Fri, 17 May 2024 12:16:15 GMT, Prasanta Sadhukhan wrote: >> Inadvertent mention of Netscape in Javadoc is removed.. > > Prasanta Sadhukhan has updated the pull request incrementally with two > additional commits since the last revision: > > - doc clarity > - doc clarity Marked as reviewed by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/CellEditor.java line 91: > 89: * cell should be selected. However, it is useful to return false to > 90: * keep the selection from changing for some types of edits, > 91: * eg. in a table that contains a column of check boxes, the user > might Most guides recommend to spell _“e.g.”_ with the period after each letter, see [an article at Grammarly](https://www.grammarly.com/blog/know-your-latin-i-e-vs-e-g/). Alternatively, it could be replaced with _“for example”_. - PR Review: https://git.openjdk.org/jdk/pull/19276#pullrequestreview-2063530879 PR Review Comment: https://git.openjdk.org/jdk/pull/19276#discussion_r1605063445
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8]
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting > the use of JNI in the following ways: > > * `System::load` and `System::loadLibrary` are now restricted methods > * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods > * binding a JNI `native` method declaration to a native implementation is now > considered a restricted operation > > This PR slightly changes the way in which the JDK deals with restricted > methods, even for FFM API calls. In Java 22, the single > `--enable-native-access` was used both to specify a set of modules for which > native access should be allowed *and* to specify whether illegal native > access (that is, native access occurring from a module not specified by > `--enable-native-access`) should be treated as an error or a warning. More > specifically, an error is only issued if the `--enable-native-access flag` is > used at least once. > > Here, a new flag is introduced, namely > `illegal-native-access=allow/warn/deny`, which is used to specify what should > happen when access to a restricted method and/or functionality is found > outside the set of modules specified with `--enable-native-access`. The > default policy is `warn`, but users can select `allow` to suppress the > warnings, or `deny` to cause `IllegalCallerException` to be thrown. This > aligns the treatment of restricted methods with other mechanisms, such as > `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. > > Some changes were required in the package-info javadoc for > `java.lang.foreign`, to reflect the changes in the command line flags > described above. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments - Changes: - all: https://git.openjdk.org/jdk/pull/19213/files - new: https://git.openjdk.org/jdk/pull/19213/files/3a0db276..789bdf48 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=06-07 Stats: 28 lines in 10 files changed: 8 ins; 2 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/19213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213 PR: https://git.openjdk.org/jdk/pull/19213
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 18:39:57 GMT, Alan Bateman wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add note on --illegal-native-access default value in the launcher help
>
> src/java.base/share/classes/java/lang/System.java line 2023:
>
>> 2021: * @throws NullPointerException if {@code filename} is {@code
>> null}
>> 2022: * @throws IllegalCallerException If the caller is in a module
>> that
>> 2023: * does not have native access enabled.
>
> The exception description is fine, just noticed the other exception
> descriptions start with a lowercase "if", this one is different.
I'll fix this. Note that in `ModuleLayer.Controller`, all `@throws` start with
capital letter, which is probably where I copied/pasted this from. I'll fix
all, except for `ModuleLayer` where, for consistency, I think upper case is
better.
> src/java.base/share/man/java.1 line 587:
>
>> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
>> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
>> 587: command-line option.
>
> "This mode disable all illegal native access except for those modules enabled
> the --enable-native-access command-line option".
>
> This can be read to mean that modules granted native access with the command
> line option is also illegal native access An alternative is to make the
> second part of the sentence a new sentence, something like "Only modules
> enabled by the --enable-native-access command line option may perform native
> access.
I've simplified the text to:
This mode disables illegal native access. That is, any illegal native access
causes an `IllegalCallerException`.
This mode will become the default in a future release.
I think it's not necessary to state again the dependency on
`--enable-native-access` as we already defined what "illegal native access"
means.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604994928
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604993505
Re: RFR: 8321428: Deprecate for removal the package java.beans.beancontext [v5]
On Wed, 15 May 2024 17:39:16 GMT, Larry Cable wrote: >> the beancontext package was added (by me) in JDK 1.2 to provide >> JavaBeans(tm) with a containment and services hierarchy. >> >> based upon concepts from OpenDoc, which was a popular component model at the >> time, the API pre-dated the addition of language features such as >> annotations, and the invention and adoption of programming design patterns >> such as "Inversion of Control" and/or "Dependency Injection". >> >> This API (package) has not evolved with either the language or current >> design trends, as such it is, at best, anachronistic, and is probably an >> anti-pattern that should be avoided. >> >> This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE** > > Larry Cable has updated the pull request incrementally with one additional > commit since the last revision: > > removed trailing whitespace reported by jcheck Marked as reviewed by aivanov (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/18569#pullrequestreview-2063230682
Re: RFR: 8332403: Anachronistic reference to Netscape Communicator in Swing API docs [v2]
> Inadvertent mention of Netscape in Javadoc is removed.. Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - doc clarity - doc clarity - Changes: - all: https://git.openjdk.org/jdk/pull/19276/files - new: https://git.openjdk.org/jdk/pull/19276/files/310635fc..fed045f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19276&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19276&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19276.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19276/head:pull/19276 PR: https://git.openjdk.org/jdk/pull/19276
Integrated: 8321428: Deprecate for removal the package java.beans.beancontext
On Mon, 1 Apr 2024 22:53:12 GMT, Larry Cable wrote: > the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) > with a containment and services hierarchy. > > based upon concepts from OpenDoc, which was a popular component model at the > time, the API pre-dated the addition of language features such as > annotations, and the invention and adoption of programming design patterns > such as "Inversion of Control" and/or "Dependency Injection". > > This API (package) has not evolved with either the language or current design > trends, as such it is, at best, anachronistic, and is probably an > anti-pattern that should be avoided. > > This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE** This pull request has now been integrated. Changeset: e0d1c4b3 Author:Larry Cable Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/e0d1c4b38c7ad2dc67f3d14b0b179b313c85fc0a Stats: 74 lines in 20 files changed: 52 ins; 0 del; 22 mod 8321428: Deprecate for removal the package java.beans.beancontext Reviewed-by: prr, tr, iris, serb, aivanov - PR: https://git.openjdk.org/jdk/pull/18569
Re: RFR: 8332403: Anachronistic reference to Netscape Communicator in Swing API docs
On Fri, 17 May 2024 03:37:21 GMT, Prasanta Sadhukhan wrote: > Inadvertent mention of Netscape in Javadoc is removed.. Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/CellEditor.java line 91: > 89: * cell should be selected. However, it is useful to return false to > 90: * keep the selection from changing for some types of edits. > 91: * eg. A table that contains a column of check boxes, the user might Suggestion: * keep the selection from changing for some types of edits, * e.g. in a table that contains a column of check boxes, the user might I think the sentence should be updated a bit, the part that stats with _“A table…”_ is not a new sentence, it shouldn't start with a capital letter, and without the preposition _“in a table”_ the sentence does not look good to me. Two lines above, *“because is most cases”* should be changed to *“because **in** most cases”*. - PR Review: https://git.openjdk.org/jdk/pull/19276#pullrequestreview-2063020854 PR Review Comment: https://git.openjdk.org/jdk/pull/19276#discussion_r1604778617
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
This looks good. Just a few minor comments where future maintainers might
appreciate comments that describe parameters.
src/java.base/share/classes/java/lang/Module.java line 332:
> 330: String caller = currentClass != null ?
> currentClass.getName() : "code";
> 331: if (jni) {
> 332: System.err.printf("""
System.err may change in a running VM. It may be that we will need to change
this at some point to use its initial setting. Not suggesting we changing it
now but we might have to re-visit this.
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2062832385
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604653749
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/ClassLoader.java line 2448:
> 2446: * Invoked in the VM class linking code.
> 2447: */
> 2448: static long findNative(ClassLoader loader, Class clazz, String
> entryName, String javaName) {
I think this is another place where `@param` descriptions would help as it's
not immediately clear that "javaName" is a method name.
src/java.base/share/classes/java/lang/Runtime.java line 39:
> 37:
> 38: import jdk.internal.access.SharedSecrets;
> 39: import jdk.internal.javac.Restricted;
Runtime has been touched for a while so you'll need to bump the copyright year.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604648529
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604650293
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Add note on --illegal-native-access default value in the launcher help src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 288: > 286: * throw exception depending on the configuration. > 287: */ > 288: void ensureNativeAccess(Module m, Class owner, String methodName, > Class currentClass, boolean jni); It might be helpful to future maintainers if we put `@param` descriptions for these parameters. I had to re-read Module.enableNativeAccess to remember the difference between the owner class and the current class. - PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604644767
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/foreign/package-info.java line 170:
> 168: * the special value {@code ALL-UNNAMED} can be used). Access to
> restricted methods
> 169: * from modules not listed by that option is deemed illegal.
> Clients can
> 170: * control how illegal access to restricted method is handled, using the
> command line
I assume this should be "to a restricted method is handled" or "to restricted
methods are handled", either would work here.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604637950
Re: RFR: 8075917: The regression-swing case failed as the text on label is not painted red with the GTK L&F [v8]
> JLabel text is not painted with the LAF defined foreground color in GTK LAF. > In GTK LAF the foreground color is retrieved by using native system APIs. Fix > is to return the foreground color if it is set by LAF defined property > otherwise return the default color by calling native APIs. > Applet based test has been converted to automatic test and check for all > installed LAFs. CI testing is green for test suite and individual test. Link > attached in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: bug id removed - Changes: - all: https://git.openjdk.org/jdk/pull/17763/files - new: https://git.openjdk.org/jdk/pull/17763/files/ee16ea28..27400b29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17763&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17763&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17763.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17763/head:pull/17763 PR: https://git.openjdk.org/jdk/pull/17763
Re: RFR: 8075917: The regression-swing case failed as the text on label is not painted red with the GTK L&F [v7]
> JLabel text is not painted with the LAF defined foreground color in GTK LAF. > In GTK LAF the foreground color is retrieved by using native system APIs. Fix > is to return the foreground color if it is set by LAF defined property > otherwise return the default color by calling native APIs. > Applet based test has been converted to automatic test and check for all > installed LAFs. CI testing is green for test suite and individual test. Link > attached in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: bug id added - Changes: - all: https://git.openjdk.org/jdk/pull/17763/files - new: https://git.openjdk.org/jdk/pull/17763/files/56268d41..ee16ea28 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17763&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17763&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17763.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17763/head:pull/17763 PR: https://git.openjdk.org/jdk/pull/17763
Re: RFR: 8075917: The regression-swing case failed as the text on label is not painted red with the GTK L&F [v7]
On Fri, 17 May 2024 07:26:27 GMT, Prasanta Sadhukhan wrote: >> Abhishek Kumar has updated the pull request incrementally with one >> additional commit since the last revision: >> >> bug id added > > test/jdk/ProblemList.txt line 673: > >> 671: javax/swing/dnd/8139050/NativeErrorsInTableDnD.java 8202765 >> macosx-all,linux-all >> 672: javax/swing/JEditorPane/6917744/bug6917744.java 8213124 macosx-all >> 673: javax/swing/JRadioButton/4314194/bug4314194.java 8298153 linux-all > > 8298153 needs to be closed then if this test is going to be deproblemlisted > or add that JBS issue in this PR Added the bug id in test. - PR Review Comment: https://git.openjdk.org/jdk/pull/17763#discussion_r1604493564
Re: RFR: 8075917: The regression-swing case failed as the text on label is not painted red with the GTK L&F [v6]
On Thu, 16 May 2024 08:48:30 GMT, Abhishek Kumar wrote: >> JLabel text is not painted with the LAF defined foreground color in GTK LAF. >> In GTK LAF the foreground color is retrieved by using native system APIs. >> Fix is to return the foreground color if it is set by LAF defined property >> otherwise return the default color by calling native APIs. >> Applet based test has been converted to automatic test and check for all >> installed LAFs. CI testing is green for test suite and individual test. Link >> attached in JBS. > > Abhishek Kumar 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 seven additional > commits since the last revision: > > - Revert back the product fix and update test to skip GTK L&F > - Merge > - separate method to get LAF defined color > - extended fix for disabled checkbox and radiobutton > - Headful tag revert back and condition check for nimbus > - jtreg tag headful removed > - JLable foreground color fix for GTK LAF test/jdk/ProblemList.txt line 673: > 671: javax/swing/dnd/8139050/NativeErrorsInTableDnD.java 8202765 > macosx-all,linux-all > 672: javax/swing/JEditorPane/6917744/bug6917744.java 8213124 macosx-all > 673: javax/swing/JRadioButton/4314194/bug4314194.java 8298153 linux-all 8298153 needs to be closed then if this test is going to be deproblemlisted or add that JBS issue in this PR - PR Review Comment: https://git.openjdk.org/jdk/pull/17763#discussion_r1604470176
