Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8]
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::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 I tested this with JavaFX and everything is working as I would expect. Without any options, I get the expected warnings, one time per modules for the three `javafx.*` modules that use JNI. If I pass the `--enable-native-access` options at runtime, listing those three modules, there is no warning. Further, I confirm that if I pass that option to jlink or jpackage when creating a custom runtime, there is no warning. - Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2072430338
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8]
On Thu, 23 May 2024 06:20:51 GMT, Alan Bateman wrote: > > Further, I confirm that if I pass that option to jlink or jpackage when > > creating a custom runtime, there is no warning. > > Great! What about jpackage without a custom runtime, wondering if > --java-options can be tested. Yes, pointing to an existing runtime works, too. In either mode (jpackage using an existing Java runtime vs running jlink to create a new one), the options specified by `jpackage --java-options` are written to the application's `.cfg` file and used when the application launcher is run. - PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2127188783
Re: professional (24-bit) sampled audio support in the Windows native implementation of libjsound
Java Sound is in the client-libs area. You can file the bug yourself at https://bugreport.java.com/ if you like, or ask the sponsor of your bug (when one steps forward) to do it. If you want to contribute your fix, please see the contributing a patch section [1] in the JDK Developers Guide for the next steps. -- Kevin [1] https://openjdk.org/guide/#i-have-a-patch-what-do-i-do On 9/30/2022 4:33 AM, magar...@gmail.com wrote: Would anyone want to sponsor the following simple bug fix? - The purpose is to enable playback and recording of 24-bit sampled audio on Windows. This is already supported on other systems. - There is no associated bug in the bug database. I noted it as a "bug" as the code misunderstands the WAVE RIFF format standards. - There will be two very small changes to one Windows native cpp file under libjsound - I have tested the changes on a jdk build of the latest code. Also, please advise which of these two groups this belongs to: client libs or core libs?
Re: Examples Of Many Java Swing Components In One Program.
It's still there. https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc/SwingSet2 Btw, client-libs-...@openjdk.org (included) is the relevant mailing list for this message, not core-libs-dev. -- Kevin On 10/11/2022 1:54 AM, David Holmes wrote: On 11/10/2022 4:38 pm, Amit wrote: Code for many Java Swing Components In One Program in case someone needs it. We used to have a Swing demo in the JDK ... don't know what happened to it. David Description: The program Examples_Of_Many_Swing_Components_In_One_Program contains examples of many swing components - that is, how to initialize them and use them. You can use code from this program in your code. Where applicable, appropriate listeners are also implemented. snip
Re: RFR: 8300169: Build failure with clang-15
On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote: > Hi all, > > Please review the fix for the build failure with clang-15. > > 1. -Wbitwise-instead-of-logical > >1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the > warning >2) src/hotspot/share/runtime/notificationThread.cpp <--- keep the code > and disable warnings >3) src/hotspot/share/runtime/serviceThread.cpp<--- keep the code > and disable warnings > > > 2. -Wdeprecated-non-prototype (all the warnings are disabled) > >1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/` > <--- keep the code and disable warnings > It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN. > >2) While compiling > src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c <--- keep > the code and disable warnings > >3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m > <--- fixed the warnings > > > 3. -Wdeprecated-builtins > >Caused by files under src/java.desktop/share/native/libharfbuzz/ <--- > fixed the warnings > >Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 > > 4. -Wgnu-folding-constant > >Caused by > src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m <--- > keep the code and disable warnings > > > Thanks. > Best regards, > Jie src/java.desktop/share/native/libharfbuzz/hb-meta.hh line 191: > 189: #define hb_int_max(T) hb_int_max::value > 190: > 191: #if defined(__GNUC__) && __GNUC__ < 5 && !defined(__clang__) Normally, such changes in third-party libraries need to be done upstream, and not locally. @prrace can confirm. - PR: https://git.openjdk.org/jdk/pull/12005
Re: RFR: 8300169: Build failure with clang-15
On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote: > Hi all, > > Please review the fix for the build failure with clang-15. > > 1. -Wbitwise-instead-of-logical > >1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the > warning >2) src/hotspot/share/runtime/notificationThread.cpp <--- keep the code > and disable warnings >3) src/hotspot/share/runtime/serviceThread.cpp<--- keep the code > and disable warnings > > > 2. -Wdeprecated-non-prototype (all the warnings are disabled) > >1) Mainly caused by files under `src/java.base/share/native/libzip/zlib/` > <--- keep the code and disable warnings > It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN. > >2) While compiling > src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c <--- keep > the code and disable warnings > >3) Caused by src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m > <--- fixed the warnings > > > 3. -Wdeprecated-builtins > >Caused by files under src/java.desktop/share/native/libharfbuzz/ <--- > fixed the warnings > >Ref: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 > > 4. -Wgnu-folding-constant > >Caused by > src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m <--- > keep the code and disable warnings > > > Thanks. > Best regards, > Jie Yes, but I would wait for @prrace to review the Harfbuzz change. - PR: https://git.openjdk.org/jdk/pull/12005
Re: RFR: 8300169: Build failure with clang-15
On Sun, 15 Jan 2023 01:56:06 GMT, Jie Fu wrote: >> src/java.desktop/share/native/libharfbuzz/hb-meta.hh line 191: >> >>> 189: #define hb_int_max(T) hb_int_max::value >>> 190: >>> 191: #if defined(__GNUC__) && __GNUC__ < 5 && !defined(__clang__) >> >> Normally, such changes in third-party libraries need to be done upstream, >> and not locally. @prrace can confirm. > >> Normally, such changes in third-party libraries need to be done upstream, >> and not locally. @prrace can confirm. > > Thanks @kevinrushforth for your review. > > Yes, it had been fixed in the upstream and I just follow it. > Please see https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-meta.hh#L202 > . > > Or did you mean we had to sync the whole harfbuzz with the upstream? > If so, I would suggest doing it in a separate PR. > What do you think? > Thanks. No, I didn't mean to update all of harfbuzz. What you've done seems fine to me, but let's see what @prrace says. - PR: https://git.openjdk.org/jdk/pull/12005
Re: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx
On Fri, 16 Sep 2022 07:35:03 GMT, Leslie Zhai wrote: > Hi, > > @dumasun reported the issue: > > Configured with jfx-ls-modular-sdk: > > > configure --with-import-modules=modular-sdk > > > `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` > failed: > > > --System.err:(11/697)-- > java.lang.RuntimeException: JavaFX modules erroneously included in the JDK > at FXLauncherTest.main(FXLauncherTest.java:451) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1589) > > JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX > modules erroneously included in the JDK > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX > modules erroneously included in the JDK > > > Thanks, > Leslie Zhai It does seem worth trying `--patch-module` if the javafx.graphics module is present in the Java runtime. If that works, it is better than skipping the test, since you will then be able to continue testing the FX launcher. Another possibility would be to go with your proposed solution of skipping the test if the javafx.graphics module is present, and provide a second test that is only run when the `javafx.graphics` module is present. In that case, you could test the actual FX launcher rather than the dummy implementation. This could either be done in this PR or as a follow-on test bug. - PR: https://git.openjdk.org/jdk/pull/10299
Re: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail with jfx
On Mon, 19 Sep 2022 00:45:32 GMT, Leslie Zhai wrote: > Hi, > > @dumasun reported the issue: > > Configured with jfx-ls-modular-sdk: > > > configure --with-import-modules=modular-sdk > > > `make run-test CONF=fastdebug > TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed: > > > --System.out:(46/3114)-- > test VerifyModuleDelegation.checkJavaBase(): success > test VerifyModuleDelegation.checkLoaderDelegation(): failure > java.lang.Error: platform/javafx.swing can't delegate to find classes from > app/jdk.unsupported.desktop > at > VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77) > at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) > at > java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) > at > VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68) > at > java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) > at > VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at > org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) > at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) > at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) > at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) > at > org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) > at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) > at > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) > at org.testng.TestRunner.privateRun(TestRunner.java:764) > at org.testng.TestRunner.run(TestRunner.java:585) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:384) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337) > at org.testng.SuiteRunner.run(SuiteRunner.java:286) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) > at org.testng.TestNG.runSuites(TestNG.java:1069) > at org.testng.TestNG.run(TestNG.java:1037) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1589) > > === > jdk/modules/etc/VerifyModuleDelegation.java > Total tests run: 2, Passes: 1, Failures: 1, Skips: 0 > === > > --System.err:(13/753)-- > WARNING: Using incubator modules: jdk.incubator.vector, > jdk.incubator.concurrent > java.lang.Exception: failures: 1 > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1589) > > > Thanks, > Leslie Zhai I haven't built a JDK using the `--with-import-modules` to include the `javafx.*` modules in quite a while, but my recollection is that yes, that did cause the JavaFX modules to be loaded by the platform class loader. The following is defined in the [`build.properties`](https://github.com/openjdk/jfx/blob/master/modules/javafx.swing/make/build.properties#L32) file for the `javafx.swing` module (as well as all other JavaFX modules), which is used by the JDK build when using `--with-import-modules`: classloader=ext I would guess that `ext` (which used to stand for the extension class loader) is causi
Re: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail with jfx
On Mon, 19 Sep 2022 00:45:32 GMT, Leslie Zhai wrote: > Hi, > > @dumasun reported the issue: > > Configured with jfx-ls-modular-sdk: > > > configure --with-import-modules=modular-sdk > > > `make run-test CONF=fastdebug > TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed: > > > --System.out:(46/3114)-- > test VerifyModuleDelegation.checkJavaBase(): success > test VerifyModuleDelegation.checkLoaderDelegation(): failure > java.lang.Error: platform/javafx.swing can't delegate to find classes from > app/jdk.unsupported.desktop > at > VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77) > at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) > at > java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) > at > VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68) > at > java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) > at > VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at > org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) > at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) > at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) > at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) > at > org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) > at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) > at > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) > at org.testng.TestRunner.privateRun(TestRunner.java:764) > at org.testng.TestRunner.run(TestRunner.java:585) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:384) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337) > at org.testng.SuiteRunner.run(SuiteRunner.java:286) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) > at org.testng.TestNG.runSuites(TestNG.java:1069) > at org.testng.TestNG.run(TestNG.java:1037) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1589) > > === > jdk/modules/etc/VerifyModuleDelegation.java > Total tests run: 2, Passes: 1, Failures: 1, Skips: 0 > === > > --System.err:(13/753)-- > WARNING: Using incubator modules: jdk.incubator.vector, > jdk.incubator.concurrent > java.lang.Exception: failures: 1 > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1589) > > > Thanks, > Leslie Zhai In that case, a solution might be to remove `ext` from the `classloader` property from all of the `modules/javafx.*/make/build.properties` files in JavaFX: classloader= or classloader=app - PR: https://git.openjdk.org/jdk/pull/10328
Re: RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx [v2]
On Sat, 17 Sep 2022 04:03:35 GMT, Leslie Zhai wrote: >> Hi, >> >> @dumasun reported the issue: >> >> Configured with jfx-ls-modular-sdk: >> >> >> configure --with-import-modules=modular-sdk >> >> >> `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` >> failed: >> >> >> --System.err:(11/697)-- >> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK >> at FXLauncherTest.main(FXLauncherTest.java:451) >> at >> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:578) >> at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:1589) >> >> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX >> modules erroneously included in the JDK >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX >> modules erroneously included in the JDK >> >> >> Thanks, >> Leslie Zhai > > Leslie Zhai has updated the pull request incrementally with one additional > commit since the last revision: > > 8293910: Try --upgrade-module-path and --patch-module but still failed How does the test fail? Does it actually find and load the "mockfx" classes, but subsequently fail? Or is it unable to patch/upgrade the javafx.graphics module with the "mockfx" classes? - PR: https://git.openjdk.org/jdk/pull/10299
Re: RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail with jfx
On Wed, 21 Sep 2022 08:35:30 GMT, Magnus Ihse Bursie wrote: > While this particular issue was closed now, this is perhaps yet another > indication that the "import modules" thing is causing problems, and should be > removed now that it is not used anymore. I created > [JDK-8294095](https://bugs.openjdk.org/browse/JDK-8294095) to explore this > possibility. Other than the issue of adding the imported FX modules in the platform classes, they are successfully using the "import modules" feature. I don't see why it needs to be removed. - PR: https://git.openjdk.org/jdk/pull/10328
Re: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v6]
On Mon, 12 Jun 2023 10:29:07 GMT, Maurizio Cimadamore
wrote:
>> Maurizio Cimadamore has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 29 commits:
>>
>> - Merge branch 'master' into javadoc_fixes
>> - Fix issue with ArithmeticException not being wrapped in IAE for
>> SequenceLayout::withElementCount
>>Fix issue with IAE thrown instead of UOE for
>> ValueLayout::arrayElementVarHandle
>>Add apiNote to MemorySegment::address re. reachability
>> - Missed a review comment
>> - Use more `{@return}` tags
>> - Address review comments
>> - Fix wrong link in layout well-formedness doc
>> - Improve javadoc on supported linker layouts
>> - Tweak javadoc of MemorySegment::get/setUtf8String to deal with overflow
>> - Merge branch 'master' into javadoc_fixes
>> - Add overflow tests
>> - ... and 19 more: https://git.openjdk.org/jdk/compare/01455a07...b59edd93
>
> Closing, as the review is complete and I have to rebase against the forked 21
> repo. A similar PR will pop up soon :-)
@mcimadamore Is there a reason that this shouldn't be integrated into the
mainline?? Absent a compelling reason, fixes should be integrated first into
the mainline (for 22) and then backported to 21.
-
PR Comment: https://git.openjdk.org/jdk/pull/14098#issuecomment-1587513641
Re: RFR: 8308645: Javadoc of FFM API needs to be refreshed
On Mon, 12 Jun 2023 15:19:51 GMT, Maurizio Cimadamore wrote: >> Btw, besides the other 2 issues this solves (from the other PR), I think >> this also solves: https://bugs.openjdk.org/browse/JDK-8255350 > >> Btw, besides the other 2 issues this solves (from the other PR), I think >> this also solves: https://bugs.openjdk.org/browse/JDK-8255350 > > Thanks for the reminder - JDK-8255350 is not fixed by this, but by > https://git.openjdk.org/jdk/pull/14007 @mcimadamore Shouldn't this go into the mainline first? - PR Comment: https://git.openjdk.org/jdk21/pull/7#issuecomment-1587561904
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update
On Mon, 12 Jun 2023 21:27:05 GMT, Justin Lu wrote: >> Please review this PR which updates the JDK's localized resources since the >> previous L10n translation drop (1/26). >> >> To help with reviewing the changes, @jonathan-gibbons created a tool which >> displays the localized changes next to the original file's changes in UTF-8 >> native. Those files can be viewed >> [here](https://cr.openjdk.org/~jlu/output/) >> >> For example, >> >> > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> >> >> >> Please note that the HTML files only apply to .properties, and not .java >> resources. > > @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves > @AlanBateman @eirbjo could you please review the modules / changes you are > familiar with, thank you. @justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21. See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html - PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588146416
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update
On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. I was > @kevinrushforth Thanks for the reminder, will make the change in ML first. Thanks. And I see you made this PR Draft, which is a good idea. Once the mainline PR is integrated, you can change the title of this PR to `Backport NNN`, where `NNN` is the 40 character commit hash of the jdk master commit. Then Skara will note this as a Backport, and also note whether it is a clean backport. - PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588176435
Re: RFR: 8309632: JDK 21 RDP1 L10n resource files update
On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu wrote: > Please review this PR which updates the JDK's localized resources since the > previous L10n translation drop (1/26). > > To help with reviewing the changes, @jonathan-gibbons created a tool which > displays the localized changes next to the original file's changes in UTF-8 > native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) > > For example, > > src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3";> > > > Please note that the HTML files only apply to .properties, and not .java > resources. Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean") - PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593724465
Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries
On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou wrote: > 8307858: [REDO] JDK-8307194 Add make target for optionally building a > complete set of all JDK and hotspot libjvm static libraries As a P4 enhancement, this doesn't meet the criteria for integration into JDK 21 during [Rampdown Phase 1](https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html). You could request late approval to get this enhancement in, via the process described in [JEP 3](https://openjdk.org/jeps/3). - PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595304249
Re: [jdk21] RFR: 8309937: Add @sealedGraph for some Panama FFM interfaces
On Mon, 19 Jun 2023 14:58:13 GMT, Per Minborg wrote: > Hi all, > > This pull request contains a backport of commit > [b412fc79](https://github.com/openjdk/jdk/commit/b412fc79c3c2548df10918090beedaf6b2d08d96) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Per Minborg on 16 Jun 2023 and > was reviewed by Maurizio Cimadamore. > > Thanks! Since this is a P4 Enhancement, you will need approval to backport this to JDK 21 during RDP1. See the "Late-Enhancement Request Process" section of [JEP 3](https://openjdk.org/jeps/3). - PR Comment: https://git.openjdk.org/jdk21/pull/34#issuecomment-1598654781
Re: [jdk21] RFR: 8309937: Add @sealedGraph for some Panama FFM interfaces
On Mon, 19 Jun 2023 14:58:13 GMT, Per Minborg wrote: > Hi all, > > This pull request contains a backport of commit > [b412fc79](https://github.com/openjdk/jdk/commit/b412fc79c3c2548df10918090beedaf6b2d08d96) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Per Minborg on 16 Jun 2023 and > was reviewed by Maurizio Cimadamore. > > Thanks! Now that it has a `noreg-doc` label it is fine. - PR Comment: https://git.openjdk.org/jdk21/pull/34#issuecomment-1598996676
Re: [jdk21] RFR: 8310105: LoongArch64 builds are broken after JDK-8304913
On Tue, 20 Jun 2023 15:49:42 GMT, Glavo wrote: > 8310105: LoongArch64 builds are broken after JDK-8304913 @Glavo If the priority of the bug, which is listed as P4, is correct (which I suspect it is not), this would not meet the criteria for integrating into JDK 21 during RDP1. If this is objectively a P2 or P3 bug, then please adjust the priority of the bug in JBS accordingly. - PR Comment: https://git.openjdk.org/jdk21/pull/39#issuecomment-1599074073
Re: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries
On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou wrote: > 8307858: [REDO] JDK-8307194 Add make target for optionally building a > complete set of all JDK and hotspot libjvm static libraries Since this Enhancement was rejected for JDK 21, this PR should be closed. - PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1601253343
Re: [jdk22] RFR: 8322041: JDK 22 RDP1 L10n resource files update
On Wed, 20 Dec 2023 19:00:50 GMT, Alisen Chung wrote: > Backport of JDK-8322041 The patch looks good. Additionally, I confirmed that the files in question are identical to those in jdk mainline after this patch is applied. It will need a "R"eviewer to approve. - Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk22/pull/22#pullrequestreview-1791515826
RFR: 8311530: Deprecate jdk.jsobject module for removal
Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead. See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios. This PR does two things: 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself. - Commit messages: - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Update javadoc - Update copyright years - Merge branch 'master' into 8311530-depr-jsobject - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test - 8311530: Deprecate jdk.jsobject module for removal Changes: https://git.openjdk.org/jdk/pull/20555/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311530 Stats: 27 lines in 7 files changed: 17 ins; 5 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20555/head:pull/20555 PR: https://git.openjdk.org/jdk/pull/20555
Re: RFR: 8311530: Deprecate jdk.jsobject module for removal
On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote: > Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it > with JavaFX instead. > > See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR > openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. > That PR describes the needed test scenarios. > > This PR does two things: > > 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates > that the module will be delivered with JavaFX > 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the > transition by allowing the version of the module shipped with JavaFX to be > used in favor of the deprecated module in the JDK itself. The GHA run shows a spurious failure in macOS (a network timeout cloning the repo). I'll rerun it with no changes to my branch. - PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2332635931
Re: RFR: 8311530: Deprecate jdk.jsobject module for removal
On Fri, 6 Sep 2024 01:52:10 GMT, Roger Riggs wrote: > Looks good. I'll review the CSR when its ready. Thanks. > The changes to make jdk.jsobject an upgradeable module looks right. Thanks for checking. My testing primarily focused on this aspect of the change, so it's pretty well tested. > I was initially surprised by the wording "will be delivered with JavaFX" but > after playing with a few alternatives I concluded that what we have is okay. Yeah, I tried a few variants and couldn't come up with anything better. - PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2334035899
Re: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906
On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs wrote: > 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 @RogerRiggs Since this is deferred out of JDK 22, you need to close this PR and open a new one against jdk22u. - PR Comment: https://git.openjdk.org/jdk22/pull/110#issuecomment-1941908401
Re: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906
On Tue, 13 Feb 2024 16:09:04 GMT, Alan Bateman wrote: >> 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 > > This is for jdk22u, not jdk22 @AlanBateman You might want to unapprove this PR (go to "Files" and submit a review with "Request Changes") UPDATE: I see you already did. - PR Comment: https://git.openjdk.org/jdk22/pull/110#issuecomment-1941917372
Re: Need for a sponsor for JDK-8313674
Also , as a helpful hint, Skara has reminded you not to force push [1]. I see that you have done this a couple times, which suggests you might be in the habit of doing this as part of your workflow. Please don't. Instead, if you need to make changes, push the changes as additional commits. Skara will squash all of the commits into a single commit with the proper title, list of reviewers, etc. Thanks. -- Kevin [1] https://github.com/openjdk/jdk/pull/19021#issuecomment-2085328329 On 5/3/2024 12:01 PM, Brian Burkhalter wrote: Hello, This is the PR [1]. This is the sequence that should be followed: 1. Align the name title of the PR with the issue. (you) 2. Continue the conversation until at least one Reviewer approves it. (one or more of us) 3. Comment with /integrate command. (you) 4. Comment with /sponsor command. (one of us). Alan might have more comments on this, and given that it is after close of business in his time zone, I don’t think we’ll see further progress before Monday. Thanks, Brian [1] https://github.com/openjdk/jdk/pull/19021 On Apr 24, 2024, at 9:23 PM, Iñigo Mediavilla wrote: For my first contribution to OpenJDK, I've started looking into JDK-8313674, an issue that falls into core-libs. According to the OpenJDK Developers’ Guide I'd need a sponsor to help me through the contribution process, would anyone be available to help me ?
Re: RFR: 8330954: Fix remaining `@since` tags in `java.base` [v3]
On Mon, 13 May 2024 18:00:27 GMT, Chen Liang wrote: >> I don't want to merge or rebase on an active PR. It should get fixed once >> this is integrated. > > Sure, this comment serves as a note to reviewers that these 2 header changes > have been committed in other changes and thus can be safely ignored. There is no harm in merging the upstream master, using `git merge`, to bring your branch more up-to-date. And it can be helpful in cases like this where it might help reviewers avoid extraneous information. It is also recommended in other cases (e.g., a long-running PR where there is a lot of drift between the PR source branch and the upstream target branch). Skara will squash all commits anyway when integrating so the results will be identical. Btw, one thing you should _not_ do is rebase a source branch of an active PR. - PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1598896706
Re: RFR: 8311530: Deprecate jdk.jsobject module for removal [v3]
> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it > with JavaFX instead. > > See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR > openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. > That PR describes the needed test scenarios. > > This PR does two things: > > 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates > that the module will be delivered with JavaFX > 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the > transition by allowing the version of the module shipped with JavaFX to be > used in favor of the deprecated module in the JDK itself. Kevin Rushforth 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 nine additional commits since the last revision: - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Update javadoc - Update copyright years - Merge branch 'master' into 8311530-depr-jsobject - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test - 8311530: Deprecate jdk.jsobject module for removal - Changes: - all: https://git.openjdk.org/jdk/pull/20555/files - new: https://git.openjdk.org/jdk/pull/20555/files/d2ff851c..7afc50ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=01-02 Stats: 56203 lines in 908 files changed: 45148 ins; 6116 del; 4939 mod Patch: https://git.openjdk.org/jdk/pull/20555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20555/head:pull/20555 PR: https://git.openjdk.org/jdk/pull/20555
Re: RFR: 8311530: Deprecate jdk.jsobject module for removal [v2]
On Mon, 23 Sep 2024 16:32:23 GMT, Kevin Rushforth wrote: >> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it >> with JavaFX instead. >> >> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR >> openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. >> That PR describes the needed test scenarios. >> >> This PR does two things: >> >> 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates >> that the module will be delivered with JavaFX >> 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the >> transition by allowing the version of the module shipped with JavaFX to be >> used in favor of the deprecated module in the JDK itself. > > Kevin Rushforth 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 eight additional > commits since the last revision: > > - Merge branch 'master' into 8311530-depr-jsobject > - Merge branch 'master' into 8311530-depr-jsobject > - Merge branch 'master' into 8311530-depr-jsobject > - Update javadoc > - Update copyright years > - Merge branch 'master' into 8311530-depr-jsobject > - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test > - 8311530: Deprecate jdk.jsobject module for removal I've created the CSRs for both the this PR and openjdk/jfx#1529. - PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2394709080
Re: RFR: 8311530: Deprecate jdk.jsobject module for removal [v4]
> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it > with JavaFX instead. > > See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR > openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. > That PR describes the needed test scenarios. > > This PR does two things: > > 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates > that the module will be delivered with JavaFX > 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the > transition by allowing the version of the module shipped with JavaFX to be > used in favor of the deprecated module in the JDK itself. Kevin Rushforth 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 10 additional commits since the last revision: - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Update javadoc - Update copyright years - Merge branch 'master' into 8311530-depr-jsobject - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test - 8311530: Deprecate jdk.jsobject module for removal - Changes: - all: https://git.openjdk.org/jdk/pull/20555/files - new: https://git.openjdk.org/jdk/pull/20555/files/7afc50ce..e9eb8fb4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=02-03 Stats: 29612 lines in 760 files changed: 24122 ins; 2746 del; 2744 mod Patch: https://git.openjdk.org/jdk/pull/20555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20555/head:pull/20555 PR: https://git.openjdk.org/jdk/pull/20555
Integrated: 8311530: Deprecate jdk.jsobject module for removal
On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote: > Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it > with JavaFX instead. > > See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR > openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. > That PR describes the needed test scenarios. > > This PR does two things: > > 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates > that the module will be delivered with JavaFX > 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the > transition by allowing the version of the module shipped with JavaFX to be > used in favor of the deprecated module in the JDK itself. This pull request has now been integrated. Changeset: 2b03dbda Author:Kevin Rushforth Committer: Roger Riggs URL: https://git.openjdk.org/jdk/commit/2b03dbdac4819bc0d40912f273a1ca7ab4e8715e Stats: 27 lines in 7 files changed: 17 ins; 5 del; 5 mod 8311530: Deprecate jdk.jsobject module for removal Reviewed-by: rriggs, alanb, erikj - PR: https://git.openjdk.org/jdk/pull/20555
Re: RFR: 8311530: Deprecate jdk.jsobject module for removal
On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote: > Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it > with JavaFX instead. > > See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR > openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. > That PR describes the needed test scenarios. > > This PR does two things: > > 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates > that the module will be delivered with JavaFX > 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the > transition by allowing the version of the module shipped with JavaFX to be > used in favor of the deprecated module in the JDK itself. Yes, this was on hold for a couple weeks; I plan to write the CSR this week. - PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2368124430
Re: RFR: 8311530: Deprecate jdk.jsobject module for removal [v2]
> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it > with JavaFX instead. > > See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR > openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. > That PR describes the needed test scenarios. > > This PR does two things: > > 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates > that the module will be delivered with JavaFX > 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the > transition by allowing the version of the module shipped with JavaFX to be > used in favor of the deprecated module in the JDK itself. Kevin Rushforth 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 eight additional commits since the last revision: - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Update javadoc - Update copyright years - Merge branch 'master' into 8311530-depr-jsobject - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test - 8311530: Deprecate jdk.jsobject module for removal - Changes: - all: https://git.openjdk.org/jdk/pull/20555/files - new: https://git.openjdk.org/jdk/pull/20555/files/c3ee6ad3..d2ff851c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=00-01 Stats: 168234 lines in 1172 files changed: 155508 ins; 7077 del; 5649 mod Patch: https://git.openjdk.org/jdk/pull/20555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20555/head:pull/20555 PR: https://git.openjdk.org/jdk/pull/20555
Re: Copyright update tedium
No, The Skara PR in question isn't proposing to do this. Rather it is checking that _if_ the Copyright header is updated, it is syntactically correct. It would be an item for further discussion to have Skara actually get into the business of whether the copyright header should be updated and what the copyright year(s) should be. I personally think Skara shouldn't do that, but it is a topic that might be worth discussing for a future Enhancement. -- Kevin On 12/9/2024 10:37 AM, Archie Cobbs wrote: Bleh, ignore my comment. I didn't realize the PR#1702 you referenced is already proposing doing this! -Archie On Mon, Dec 9, 2024 at 10:45 AM Archie Cobbs wrote: Thanks for working on this... something of a thankless task :) I'm sure you've considered this but I'll ask anyway. Would it make (more or less) sense to try and enforce the policy on the front-end? By that I mean adding another checkbox requirement to skara's handling of PR's: "🔲 Change must update copyright dates where applicable" The check could start out being conservative: * Only applies to files with certain extensions and/or matching some filter list * Only applies to files containing a recognizable copyright text line -Archie On Mon, Dec 9, 2024 at 7:06 AM Magnus Ihse Bursie wrote: I felt responsibility for the .github files, and wanted to check if there were more build system files needed updating. So I ran a more comprehensive script, and discovered a *lot* more files that needed updating. Like a thousand or so... I have opened a series of issues starting at https://bugs.openjdk.org/browse/JDK-8345793 and going up to https://bugs.openjdk.org/browse/JDK-8345805 to update these headers. I agree, this should be automated. We're starting to slowly get there, see https://github.com/openjdk/skara/pull/1702 for a first step. /Magnus On 2024-12-03 16:45, Archie Cobbs wrote: Dumb question... It seems like the thing with updating copyright years in source files could be better automated. At least, couldn't there be a test that fails if you forget? FWIW my little updater script says that these files still need to be updated to 2024: .github/actions/config/action.yml .github/actions/do-build/action.yml .github/actions/get-bootjdk/action.yml .github/actions/get-bundles/action.yml .github/actions/get-msys2/action.yml .github/scripts/gen-build-failure-report.sh .github/scripts/gen-test-summary.sh .github/workflows/build-cross-compile.yml .github/workflows/test.yml src/java.base/share/classes/jdk/internal/org/xml/sax/Attributes.java src/java.base/share/classes/jdk/internal/org/xml/sax/InputSource.java src/java.base/share/classes/jdk/internal/org/xml/sax/SAXException.java src/java.base/share/classes/jdk/internal/org/xml/sax/SAXParseException.java src/java.base/share/classes/jdk/internal/org/xml/sax/XMLReader.java src/java.base/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java src/java.base/share/classes/jdk/internal/platform/Metrics.java test/hotspot/jtreg/compiler/vectorization/runner/BasicIntOpTest.java test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java test/hotspot/jtreg/compiler/whitebox/DeoptimizeFramesTest.java -Archie -- Archie L. Cobbs -- Archie L. Cobbs -- Archie L. Cobbs
Re: [jdk24] RFR: 8347302: Mark test tools/jimage/JImageToolTest.java as flagless
On Mon, 13 Jan 2025 02:59:52 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit > [e7e8f60c](https://github.com/openjdk/jdk/commit/e7e8f60c9bedd5622525cc4339300b438eedc9fd) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24. > > Test test/jdk/tools/jimage/JImageToolTest.java ignore vm flags and should be > marked as flagless. Test-fix only, no risk. > > Thanks! As we are now in the [Release Candidate phase of JDK 24](https://openjdk.org/projects/jdk/24/), this fix is no longer suitable for JDK 24. See [JEP 3](https://openjdk.org/jeps/3) for more information. - PR Comment: https://git.openjdk.org/jdk/pull/23058#issuecomment-2643256756
[jdk24] Withdrawn: 8347302: Mark test tools/jimage/JImageToolTest.java as flagless
On Mon, 13 Jan 2025 02:59:52 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit > [e7e8f60c](https://github.com/openjdk/jdk/commit/e7e8f60c9bedd5622525cc4339300b438eedc9fd) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24. > > Test test/jdk/tools/jimage/JImageToolTest.java ignore vm flags and should be > marked as flagless. Test-fix only, no risk. > > Thanks! This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/23058
Re: Will jpackage support WixTools v4 or v5 with Java 24?
Yes, jpackage will support either v4 or v5 as of JDK 24: https://bugs.openjdk.org/browse/JDK-8319457 You can also see this in the early access release notes: https://jdk.java.net/24/release-notes (bottom of the page) -- Kevin On 12/11/2024 12:28 PM, Davide Perini wrote: As subject. Current wix v3 is deprecated. Will jpackage support WixTools v4 or v5 with Java 24? Thanks
Re: RFR: 8346069: Add missing Classpath exception statements
On Thu, 12 Dec 2024 08:04:38 GMT, Sorna Sarathi wrote: > This PR adds missing Classpath exception statements in several files. > > JDK Issue: [JDK-8346069](https://bugs.openjdk.org/browse/JDK-8346069) This looks correct to me. The missing Classpath exception was not intentional. This should be backported to `jdk24` after it is integrated into mainline. - Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/22704#pullrequestreview-2500765557
Re: [jdk24] RFR: 8346069: Add missing Classpath exception statements
On Tue, 17 Dec 2024 08:04:25 GMT, Sorna Sarathi N wrote: > Hi all, > > This pull request contains a backport of > [openjdk/jdk#22704](https://github.com/openjdk/jdk/pull/22704.) > > The commit being backported was authored by Sorna Sarathi on 13 Dec 2024 and > was reviewed by Amit Kumar, Alexey Semenyuk, Iris Clark and Kevin Rushforth. > > Thanks! @irisclark Can you review this backport? - PR Comment: https://git.openjdk.org/jdk/pull/22785#issuecomment-2554655611
Re: [jdk24] RFR: 8344611: Add missing classpath exception
On Tue, 17 Dec 2024 07:49:31 GMT, Sorna Sarathi N wrote: > Hi all, > > This pull request contains a backport of commit > [458979d8](https://github.com/openjdk/jdk/commit/458979d83ac784273263b54516369d79764010dd) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Sorna Sarathi on 9 Dec 2024 and > was reviewed by Amit Kumar and Iris Clark. > > Thanks! @irisclark Can you review this backport? - PR Comment: https://git.openjdk.org/jdk/pull/22784#issuecomment-2554655087
Re: [jdk24] RFR: 8346069: Add missing Classpath exception statements
On Tue, 17 Dec 2024 08:04:25 GMT, Sorna Sarathi N wrote: > Hi all, > > This pull request contains a backport of > [openjdk/jdk#22704](https://github.com/openjdk/jdk/pull/22704.) > > The commit being backported was authored by Sorna Sarathi on 13 Dec 2024 and > was reviewed by Amit Kumar, Alexey Semenyuk, Iris Clark and Kevin Rushforth. > > Thanks! Looks good, and I confirm that it is a clean backport. It will need a review by someone with a Reviewer role in the jdk project. - Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/22785#pullrequestreview-2516134801
Re: RFR: 8346739: jpackage tests failed after JDK-8345259
On Fri, 20 Dec 2024 19:02:38 GMT, Mandy Chung wrote: > A few jpackage tests invoke `jlink --add-modules ALL-MODULE-PATH` without > `--module-path` and they now fail because of JDK-8345259 which requires > `--module-path` to be set when `ALL-MODULE-PATH` is used. The fix is to add > `--add-modules $JAVA_HOME/jmods` which was the default before JDK-8345259. A > separate issue is needed to skip these tests when running on a linkable > runtime image without the packaged modules. @alexeysemenyukoracle @jerboaa Can you review? - PR Comment: https://git.openjdk.org/jdk/pull/22853#issuecomment-2557594476
Re: RFR: 8346739: jpackage tests failed after JDK-8345259
On Fri, 20 Dec 2024 19:02:38 GMT, Mandy Chung wrote: > A few jpackage tests invoke `jlink --add-modules ALL-MODULE-PATH` without > `--module-path` and they now fail because of JDK-8345259 which requires > `--module-path` to be set when `ALL-MODULE-PATH` is used. The fix is to add > `--add-modules $JAVA_HOME/jmods` which was the default before JDK-8345259. A > separate issue is needed to skip these tests when running on a linkable > runtime image without the packaged modules. Looks good to me. - Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/22853#pullrequestreview-2518208291
Re: RFR: 8346739: jpackage tests failed after JDK-8345259
On Fri, 20 Dec 2024 19:02:38 GMT, Mandy Chung wrote: > A few jpackage tests invoke `jlink --add-modules ALL-MODULE-PATH` without > `--module-path` and they now fail because of JDK-8345259 which requires > `--module-path` to be set when `ALL-MODULE-PATH` is used. The fix is to add > `--add-modules $JAVA_HOME/jmods` which was the default before JDK-8345259. A > separate issue is needed to skip these tests when running on a linkable > runtime image without the packaged modules. Yes, that seems like the best approach to get these failing tests running again. - PR Comment: https://git.openjdk.org/jdk/pull/22853#issuecomment-2557609223
Re: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348
On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote:
> Please review this workaround for the compiler error on Windows. This error
> occurs in closed build with custom make logic that uses zip_util.c. The error
> indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the macro on
> Windows for now until the cause is fully understood.
>
>
> [2025-01-28T16:57:35,721Z]
> c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94):
> error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad'
> [2025-01-28T16:57:35,721Z]
> c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94):
> error C2085: 'ZFILE_Open': not in formal parameter list
> [2025-01-28T16:57:35,737Z]
> c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94):
> error C2143: syntax error: missing ';' before '{'
> [2025-01-28T16:57:35,737Z]
> c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(776):
> warning C4013: 'ZFILE_Open' undefined; assuming extern returning int
@alexeysemenyukoracle please review
-
PR Comment: https://git.openjdk.org/jdk/pull/23340#issuecomment-2619884181
Re: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348
On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote:
> Please review this workaround for the compiler error on Windows. This error
> occurs in closed build with custom make logic that uses zip_util.c. The error
> indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the macro on
> Windows for now until the cause is fully understood.
>
>
> [2025-01-28T16:57:35,721Z]
> c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94):
> error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad'
> [2025-01-28T16:57:35,721Z]
> c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94):
> error C2085: 'ZFILE_Open': not in formal parameter list
> [2025-01-28T16:57:35,737Z]
> c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94):
> error C2143: syntax error: missing ';' before '{'
> [2025-01-28T16:57:35,737Z]
> c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(776):
> warning C4013: 'ZFILE_Open' undefined; assuming extern returning int
Since the only failures we've seen are on Windows, this fix should work. Alexey
will be able to confirm this.
-
Marked as reviewed by kcr (Author).
PR Review: https://git.openjdk.org/jdk/pull/23340#pullrequestreview-2579235302
Re: RFR: 8348892: Properly fix compilation error for zip_util.c on Windows
On Tue, 28 Jan 2025 22:42:00 GMT, Alexey Semenyuk wrote: > Reapply [JDK-8348348](https://bugs.openjdk.org/browse/JDK-8348348) This looks good. I confirm that this is the correct backout patch for[JDK-834](https://bugs.openjdk.org/browse/JDK-834), thus resotring the fix for[JDK-8348348](https://bugs.openjdk.org/browse/JDK-8348348). @jianglizhou Can you also review? - Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/23344#pullrequestreview-2579582484 PR Comment: https://git.openjdk.org/jdk/pull/23344#issuecomment-2620212653
Re: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348
On Tue, 28 Jan 2025 19:54:21 GMT, Alexey Semenyuk wrote:
> > zip_util.c(94): error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad'
>
> It doesn't look like it complains about undefined DEF_STATIC_JNI_OnLoad
The compilation error I saw did.
A Mach5 job I submitted passed in one case where it was failing, so I think the
fix is good.
@alexeysemenyukoracle Please confirm, though.
-
PR Comment: https://git.openjdk.org/jdk/pull/23340#issuecomment-2619955687
Re: RFR: 8254622: Hide superclasses from conditionally exported packages [v2]
On Tue, 8 Apr 2025 09:02:25 GMT, Hannes Wallnöfer wrote: >> Please review an enhancement to treat classes and interfaces that are not >> included and not unconditionally exported as hidden. This means they do not >> show up in the generated documentation even if they are implemented or >> extended by a documented type. >> >> This change makes the `@hidden` JavaDoc tag unnecessary in two internal base >> classes that previously used it, `jdk.internal.vm.vector.VectorSupport` and >> `jdk.internal.event.Event`. The generated documentation is unchanged. >> >> The change also adds support for the `@hidden` JavaDoc tag in interfaces, >> which was previously missing, and adds coverage to `TestHiddenTag.java`. > > Hannes Wallnöfer has updated the pull request incrementally with one > additional commit since the last revision: > > Review feedback: add Utils.isVisible(TypeElement) method I didn't review the code changes, but I did test this by building the JDK with this fix and using the javadoc tool from that JDK to build the JavaFX docs. The non-exported intermediate classes that we currently see (without this PR) in the class hierarchy are now elided from the docs as expected. - Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/24446#pullrequestreview-2761262117
Re: RFR: 8359830: Incorrect os.version reported on macOS Tahoe 26 (Beta)
On Wed, 18 Jun 2025 06:01:43 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address the issue > noted in https://bugs.openjdk.org/browse/JDK-8359830? > > macOS operating system's newer version 26 (currently in Beta) is reported as > a 16 by older versions of XCode. JDK internally uses the `NSProcessInfo` and > `NSOperatingSystemVersion` APIs to identify the macOS version and set the > `os.version` system property to that value. The current recommended version > to build the JDK on macOS is XCode 15.4. The `NSOperatingSystemVersion` API > on that version of XCode reports macOS version as 16 instead of 26. > > The commit in this PR updates the JDK code to handle this mismatch and set > the `os.version` appropriately to 26. This fix is similar to what we did with > macOS BigSur when the macOS version 10.16 was meant to mean 11 > https://bugs.openjdk.org/browse/JDK-8253702. > > The existing `OsVersionTest` has been updated for some trivial clean up. > Existing tests in tier1, tier2 and tier3 continue to pass with this change. > If anyone has access to a macOS 26 Beta, I request them to build this change > and run `tier1` tests to help verify that there aren't any failures. LGTM I tested this on macOS 26. Without this patch `os.version` is set to `16`; with this patch, it is correctly set to `26`. I left one possible suggestion, if you want to consider it. src/java.base/macosx/native/libjava/java_props_macosx.c line 242: > 240: const bool versionCompatEnabled = envVal != NULL && strncmp(envVal, > "1", 1) == 0; > 241: const bool requiresSpecialHandling = ((long) osVer.majorVersion == > 10 && (long) osVer.minorVersion >= 16) > 242: || ((long) osVer.majorVersion > == 16 && (long) osVer.minorVersion >= 0); Since we know Apple jumped from 15 --> 26, would it be more future-proof to change this test to something like this? osVer.majorVersion >= 16 && osVer.majorVersion < 26 This would allow us to work when macOS 27 comes out, in case it reports itself as "17.0" if we don't update the version of Xcode before then. I can also see the argument for leaving it as you have done. And my guess is that Apple will report macOS 27 as 27 regardless, so this probably doesn't matter. - Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/25865#pullrequestreview-2939998221 PR Review Comment: https://git.openjdk.org/jdk/pull/25865#discussion_r2155070320
Re: RFR: 8355746: Start of release updates for JDK 26 [v6]
On Tue, 3 Jun 2025 11:10:30 GMT, Nizar Benalla wrote: > I have problemlisted > `tools/sincechecker/modules/java.base/JavaBaseCheckSince.java` as it is > failing due to the symbol information lagging behind. What is your plan for addressing this? In its current state, that problem list entry will prevent integration. If you intend to integrate this PR with that test problem listed, you will need to file a new bug and use that bug ID in the problem list. - PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2941383168
Re: RFR: 8355746: Start of release updates for JDK 26 [v7]
On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into jdk.8355746 > - Problemlist JavaBaseCheckSince > - Revert "feedback: never bump ASM version" > >This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 >The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 test/jdk/ProblemList.txt line 843: > 841: # jdk_since_checks > 842: > 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 > generic-all You will need a different bug ID in order to problem list this test. It is an integration blocker to use the bug ID of a bug being fixed in the problem list. - PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127408934
Re: RFR: 8355746: Start of release updates for JDK 26 [v7]
On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into jdk.8355746 > - Problemlist JavaBaseCheckSince > - Revert "feedback: never bump ASM version" > >This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 >The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 test/jdk/ProblemList.txt line 843: > 841: # jdk_since_checks > 842: > 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 > generic-all Suggestion: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8358627 generic-all @nizarbenalla Per our offline discussion, I created [JDK-8358627](https://bugs.openjdk.org/browse/JDK-8358627) to track this. - PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127497730
