Re: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test code

2022-10-18 Thread Phil Race
On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie wrote: > This is a continuation of the effort to update all our URLs to the new > top-level domain. > > This patch updates (most) URLs in testing code. There still exists references > to openjdk.java.net, but that are not strictly used as no

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-10-31 Thread Phil Race
On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` >> to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components >> according to the escaping mechanism defin

Re: RFR: 8294241: Deprecate URL public constructors [v3]

2022-11-01 Thread Phil Race
On Tue, 1 Nov 2022 16:10:47 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` >> to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components >> according to the escaping mechanism define

Re: RFR: 8296546: Add @spec tags to API [v3]

2022-11-28 Thread Phil Race
On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc >> comments, as appropriate, to leverage the recent new javadoc feature to >> generate a new page listing the references to all external specifications >> li

Re: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase

2023-08-14 Thread Phil Race
On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to > have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > Th

Re: RFR: 8317696: Fix compilation with clang-16 [v3]

2023-10-10 Thread Phil Race
On Mon, 9 Oct 2023 18:29:26 GMT, Alexey Ivanov wrote: >> Jan Kratochvil has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove declaration changes which are not required >>- suggested by djelinski > > src/java.desktop/unix/native/com

Re: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase [v2]

2023-11-15 Thread Phil Race
On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken wrote: >> Currently there is a number of functionality that would be interesting to >> have for shared lib load operations in the JDK C code. >> Some examples : >> Events::log_dll_message for hs-err files reporting >> JFR event NativeLibraryLoad

Re: RFR: 8325163: Enable -Wpedantic on clang [v2]

2024-02-16 Thread Phil Race
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote: >> Inspired by (the later backed-out) >> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to >> enable `-Wpedantic` for clang. This has already found some irregularities in >> the code, like mistakenly using `#impo

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8]

2024-05-20 Thread Phil Race
On Fri, 17 May 2024 13:38:25 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::loa

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8]

2024-05-20 Thread Phil Race
On Mon, 13 May 2024 10:49:30 GMT, Maurizio Cimadamore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Address review comments > > make/conf/module-loader-map.conf line 105: > >> 103: java.smartcardio \

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8]

2024-05-21 Thread Phil Race
On Fri, 17 May 2024 13:38:25 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::loa

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-21 Thread Phil Race
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8340326: Remove references to Applet in core-libs/security tests [v8]

2024-10-03 Thread Phil Race
On Thu, 3 Oct 2024 18:15:55 GMT, Justin Lu wrote: >> Please review this PR which removes usages of Applet within the corelibs >> tests. >> >> Most changes are removed comments/updated var names. The JBS issue lists >> more files than the ones included in this pull request, please see the >> c

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-22 Thread Phil Race
On Tue, 22 Oct 2024 15:22:08 GMT, Sean Mullan wrote: >> test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26: >> >>> 24: import javax.swing.SwingUtilities; >>> 25: import javax.swing.plaf.basic.BasicComboBoxEditor; >>> 26: /* >> >> I think we have finally decided that jtr

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v4]

2024-10-28 Thread Phil Race
On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v9]

2024-11-08 Thread Phil Race
On Fri, 8 Nov 2024 13:49:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main cha

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-11-08 Thread Phil Race
On Fri, 1 Nov 2024 18:06:47 GMT, Alexey Ivanov wrote: > > I'd not looked at this test before but when I do the thing I noticed is > > that createPrivateValue is no longer used. But I don't see a problem with > > keeping the rest of the test. > > @prrace Do I understand correctly that _“`create

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-23 Thread Phil Race
On Wed, 23 Oct 2024 05:11:19 GMT, Prasanta Sadhukhan wrote: >> Sean Mullan has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 97 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Change apiNo

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-23 Thread Phil Race
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8340326: Remove references to Applet in core-libs/security tests [v2]

2024-09-25 Thread Phil Race
On Wed, 25 Sep 2024 22:03:59 GMT, Justin Lu wrote: > Not sure if it will be ran by anyone as it is manual, I don't know about other vendors, but for Oracle, manual tests are run at least once on every release some time after RDP1 and before RDP2. - PR Comment: https://git.openjd

Re: RFR: 8340326: Remove references to Applet in core-libs/security tests [v4]

2024-09-26 Thread Phil Race
On Thu, 26 Sep 2024 16:25:21 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> review: update wording of instructions > > test/jdk/java/util/TimeZone/DefaultTimeZoneTest.java line 80: > >> 78:

Re: RFR: 8340326: Remove references to Applet in core-libs/security tests [v7]

2024-10-03 Thread Phil Race
On Fri, 27 Sep 2024 18:08:54 GMT, Justin Lu wrote: >> Please review this PR which removes usages of Applet within the corelibs >> tests. >> >> Most changes are removed comments/updated var names. The JBS issue lists >> more files than the ones included in this pull request, please see the >>

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-25 Thread Phil Race
On Fri, 25 Oct 2024 21:23:26 GMT, Harshitha Onkar wrote: >> The tests with “Audit Core Reflection” in their summary fall into this >> category, we may consider removing them. > > @prrace Can you please advice on “Audit Core Reflection” category of tests. > I'm not 100% sure if these tests need

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

2024-10-25 Thread Phil Race
On Fri, 25 Oct 2024 21:06:28 GMT, Harshitha Onkar wrote: >> test/jdk/javax/imageio/spi/AppletContextTest/IIOPluginTest.java line 42: >> >>> 40: } catch (ServiceConfigurationError sce) { >>> 41: System.out.println("Expected ServiceConfigurationError \n" >>> + sce); >>> 42:

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager

2024-10-15 Thread Phil Race
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote: > This is the implementation of JEP 486: Permanently Disable the Security > Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The > [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the > main change

Re: RFR: 8345799: Update copyright year to 2024 for core-libs in files where it was missed [v3]

2024-12-10 Thread Phil Race
On Tue, 10 Dec 2024 09:31:21 GMT, Prasanta Sadhukhan wrote: > not sure why client label is added, no java.desktop/accessibility files are > in there I was puzzling over that too. - PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2532895836

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-09 Thread Phil Race
On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth wrote: > > test/jdk/java/awt/font/NumericShaper/MTTest.java > > ``` > > * * @run main/timeout=300/othervm MTTest > > > > > > * * @run main/timeout=1200/othervm MTTest > > ``` > > > > > > > > > > > > > > > > > > > >

Re: RFR: 8356644: Update encoding declaration to UTF-8

2025-05-09 Thread Phil Race
On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote: > A handful of html and xml files in the JDK source tree claims to have > encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files. > > While perhaps technically correct, this is misleading, and goes contrary to > the eff

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread Phil Race
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code

2025-06-18 Thread Phil Race
On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeliński wrote: > Add an exception check after a JNI static method call, and re-enable checks > for CallStatic in JNICheck.sh test. > > I verified that the JNICheck test is passing on all headless and headful > platforms I had access to (Windows, Linux