From alanb at openjdk.org Sun Feb 1 17:09:03 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 1 Feb 2026 17:09:03 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code [v2] In-Reply-To: References:

Message-ID: <1Cq67E6TRRmlrAgIqTbKoOSzHB2owQSMMFzzqThcGPY=.c2a078ad-fd02-4a49-a389-e4df07ed5681@github.com> On Fri, 30 Jan 2026 12:41:33 GMT, Matthias Baesken wrote: >> libjimage has a few unused functions/methods; those are listed when logging elimination with -Wl,--gc-sections -Wl,--print-gc-sections . >> We could remove them (or with if are still needed for completeness put them into #if 0 ) to reduce lib size on Linux and AIX. >> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust COPYRIGHT headers Hi Matthias, As luck would have it I'm also about to make some substantive changes to this code (based on Valhalla work). These changes also remove most of the same dead-code you've identified, but I'd need to check that your work doesn't muddle my integration (see draft PR at): https://github.com/openjdk/jdk/pull/29414/changes#diff-aa601f760164d2f192a65e314d0c29224d4e812f492094aeb4fbc8be95d0b853 I'm happy to roll in any additional dead code you've identified into my PR if that makes things easier. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3834397108 From mbaesken at openjdk.org Mon Feb 2 11:14:47 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 2 Feb 2026 11:14:47 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code [v2] In-Reply-To: <1Cq67E6TRRmlrAgIqTbKoOSzHB2owQSMMFzzqThcGPY=.c2a078ad-fd02-4a49-a389-e4df07ed5681@github.com> References:

<1Cq67E6TRRmlrAgIqTbKoOSzHB2owQSMMFzzqThcGPY=.c2a078ad-fd02-4a49-a389-e4df07ed5681@github.com> Message-ID: On Mon, 2 Feb 2026 10:53:40 GMT, David Beaumont wrote: > I'm happy to roll in any additional dead code you've identified into my PR if that makes things easier. I think this makes sense. So please compare your PR with what I removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3834488249 From lkorinth at openjdk.org Mon Feb 2 12:54:49 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 2 Feb 2026 12:54:49 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base Message-ID: Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` `module_file2.cpp_CXXFLAGS+=-Wconversion` this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) ------------- Commit messages: - 8376892: Allow conversion warnings in subsets of the code base Changes: https://git.openjdk.org/jdk/pull/29523/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376892 Stats: 52 lines in 4 files changed: 51 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29523.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29523/head:pull/29523 PR: https://git.openjdk.org/jdk/pull/29523 From lkorinth at openjdk.org Mon Feb 2 12:54:49 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 2 Feb 2026 12:54:49 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 12:45:50 GMT, Leo Korinth wrote: > Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. > > My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. > > With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. > > This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. > > The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` > `module_file2.cpp_CXXFLAGS+=-Wconversion` > > this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > > (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) I will revert the line `$(call overrideFlags,$(TOPDIR)/src/hotspot/share/gc/g1,g1ConcurrentMark.cpp,_CXXFLAGS,$(CFLAGS_CONVERSION_WARNINGS)), ` if I integrate. The line is there to show the compilation error when adding conversion warnings. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29523#issuecomment-3834925512 From erikj at openjdk.org Mon Feb 2 14:47:41 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 2 Feb 2026 14:47:41 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base In-Reply-To: References: Message-ID: <3huYgPovCwX297Y-JiWgcUmGrmkOLK10r9lbESnTa5s=.7adf08b5-0f42-493c-9df8-38333fd23f06@github.com> On Mon, 2 Feb 2026 12:45:50 GMT, Leo Korinth wrote: > Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. > > My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. > > With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. > > This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. > > The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` > `module_file2.cpp_CXXFLAGS+=-Wconversion` > > this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > > (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) make/common/MakeBase.gmk line 144: > 142: $(eval $(call SetupLogging)) > 143: > 144: ################################################################################ Could you add a description of what this section tries to do and how to use it here? Something similar to the PR comment. make/common/MakeBase.gmk line 180: > 178: > 179: # $(call overrideFlags,dir,%.cpp,_CXXFLAGS,-Wconversion) -> file1.cpp_CXXFLAGS#+-Wconversion file2.cpp_CXXFLAGS#+-Wconversion > 180: overrideFlags = $(foreach file,$(call filterFiles,$1,$2,),$(call quoteAppend,$(file)$3,$4)) I think this is the only macro here that is meant to be called by users. It would help if you could move it to either the top or the bottom and give it a proper description on now it is expected to be used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2754683287 PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2754694086 From duke at openjdk.org Mon Feb 2 16:55:04 2026 From: duke at openjdk.org (David Beaumont) Date: Mon, 2 Feb 2026 16:55:04 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code [v2] In-Reply-To: References:

Message-ID: On Fri, 30 Jan 2026 12:41:33 GMT, Matthias Baesken wrote: >> libjimage has a few unused functions/methods; those are listed when logging elimination with -Wl,--gc-sections -Wl,--print-gc-sections . >> We could remove them (or with if are still needed for completeness put them into #if 0 ) to reduce lib size on Linux and AIX. >> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust COPYRIGHT headers Marked as reviewed by alanb (Reviewer). Thanks for checking/. ------------- PR Review: https://git.openjdk.org/jdk/pull/29502#pullrequestreview-3740755279 PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3836487503 From lkorinth at openjdk.org Mon Feb 2 17:17:46 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 2 Feb 2026 17:17:46 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base In-Reply-To: <3huYgPovCwX297Y-JiWgcUmGrmkOLK10r9lbESnTa5s=.7adf08b5-0f42-493c-9df8-38333fd23f06@github.com> References: <3huYgPovCwX297Y-JiWgcUmGrmkOLK10r9lbESnTa5s=.7adf08b5-0f42-493c-9df8-38333fd23f06@github.com> Message-ID: On Mon, 2 Feb 2026 14:41:35 GMT, Erik Joelsson wrote: >> Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. >> >> My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. >> >> With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. >> >> This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. >> >> The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` >> `module_file2.cpp_CXXFLAGS+=-Wconversion` >> >> this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> >> (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) > > make/common/MakeBase.gmk line 144: > >> 142: $(eval $(call SetupLogging)) >> 143: >> 144: ################################################################################ > > Could you add a description of what this section tries to do and how to use it here? Something similar to the PR comment. Yes. > make/common/MakeBase.gmk line 180: > >> 178: >> 179: # $(call overrideFlags,dir,%.cpp,_CXXFLAGS,-Wconversion) -> file1.cpp_CXXFLAGS#+-Wconversion file2.cpp_CXXFLAGS#+-Wconversion >> 180: overrideFlags = $(foreach file,$(call filterFiles,$1,$2,),$(call quoteAppend,$(file)$3,$4)) > > I think this is the only macro here that is meant to be called by users. It would help if you could move it to either the top or the bottom and give it a proper description on now it is expected to be used. I will do so. I think `quoteAppend` might also be useful as a general way to send "variable packs" or "varargs" and possibly used by others. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2755409462 PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2755405721 From duke at openjdk.org Mon Feb 2 17:29:37 2026 From: duke at openjdk.org (David Beaumont) Date: Mon, 2 Feb 2026 17:29:37 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code [v2] In-Reply-To: References:

Message-ID: On Wed, 7 Jun 2023 10:36:19 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Just a fyi for anyone that stumbles upon this PR trying to figure out how to screenshot in Wayland, but finds out that, even when using JDK 21+, the screenshots are still black: If you are using KDE Plasma with fractional scaling (I use 150%) the capture will always fail with callbackScreenCastStart:745 available screen count 1 rebuildScreenData:116 ==== screenId#98 rebuildScreenData:161 ----------------------- rebuildScreenData:162 screenId#98 || bounds x 0 y 0 w 1707 h 960 || capture area x 0 y 0 w 0 h 0 shouldCapture 0 rebuildScreenData:163 #---------------------# callbackScreenCastStart:751 rebuildScreenData result |0| callbackScreenCastStart:764 restore_token |5b0f7d56-d05f-483e-a85a-99727b3a36f6| storeRestoreToken:805 saving token, old: |16521d36-3b86-4b25-b990-319ce54e3283| > new: |5b0f7d56-d05f-483e-a85a-99727b3a36f6| portalScreenCastStart:843 ScreenCastResult |0| initAndStartSession:1116 portalScreenCastStart result |0| checkCanCaptureAllRequiredScreens:991 Could not find required screen 0 0 2560 1440 in allowed bounds getPipewireFd:1132 The location of the screens has changed, the capture area is outside the allowed area. Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl:1036 Screencast attempt failed with -12, re-trying... The reason is because it keeps trying to find the bounds with the "logical" resolution size (the size without any scaling) and it keeps failing because the Screencast API gives the scaled resolution size. Using the default non-scaled resolution fixes the issue, but that's quite annoying so I think this should be reported on the bug tracker later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-3836935621 From rriggs at openjdk.org Mon Feb 2 18:42:36 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 2 Feb 2026 18:42:36 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code [v2] In-Reply-To: References:

Message-ID: On Mon, 2 Feb 2026 17:27:02 GMT, David Beaumont wrote: > This doesn't overlap with anything I'm changing, so for my perspective, it's all good. Thanks for checking ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3837005933 From mbaesken at openjdk.org Mon Feb 2 18:49:51 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 2 Feb 2026 18:49:51 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code [v2] In-Reply-To: References:

Message-ID: On Sat, 31 Jan 2026 16:24:58 GMT, Alan Bateman wrote: > > but this is not unused/uncalled in our codebase. I think it is inlined at the 1 or 2 points were it is used. But the method is still generated into the library even in case that it is always inlined ; it may be difficult to address this with the usual linker settings on Linux (means without linktime-gc or LTO or similar stuff ) . > > That is a bit unnerving but if someone were to use this warning to remove code that is used then there would be build or test failures. Sure, we cannot remove such code. I tested a little bit and in some C coding, with always-inline attributes added I could force that such a function is always inlined **_AND_** was removed from the lib. But this seems not to work well with C++ methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3837015503 From mbaesken at openjdk.org Mon Feb 2 18:49:55 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 2 Feb 2026 18:49:55 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code [v2] In-Reply-To: References:

<4T5cSAaROTH9gsM3k0xeQxujShyN7JaW_E6TCewGTjY=.0349f633-1b2f-439b-a09d-7de741f794ac@github.com> Message-ID: On Fri, 30 Jan 2026 12:53:34 GMT, Alexey Ivanov wrote: >>> @ThomasDevoogdt A PR isn't announced on the mailing list until it's _ready for review_ which includes a valid JBS bug. >>> >>> I suggest you write an email to build-dev and client-libs-dev mailing lists to propose this change and discuss it. I haven't found an existing issue in JBS for not requiring X11 libraries in headless mode. I can submit one on your behalf. >>> >>> If I have time, I'll test your patch locally and run it in the Oracle CI. >> >> All our build systems have X11. So a test build there doesn't prove much, and also it can easily regress. > >> > If I have time, I'll test your patch locally and run it in the Oracle CI. >> >> All our build systems have X11. So a test build there doesn't prove much, and also it can easily regress. > > This is why I'm going to use a VM which doesn't have X11 headers installed. > >> is that a reason to not merge this kind of code? > > I think it's a good change. Looking at the history at which @dholmes-ora pointed, building headless JDK without X11 was supported, but it has become broken again. I am fine with this (once @aivanov-jdk has done the test build). I am just pointing out that it has apparently regressed before so could regress again because this configuration is not part of our testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3837497493 From duke at openjdk.org Tue Feb 3 03:33:27 2026 From: duke at openjdk.org (duke) Date: Tue, 3 Feb 2026 03:33:27 GMT Subject: Withdrawn: 8349546: Linux support for Kerberos "nativeccache" functionality In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 22:04:52 GMT, Nick Hall wrote: > _Purpose_ > > This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. > > _Rationale_ > > Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. > > The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). > > Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. > > _Implementation Detail_ > > Note that there were multiple possible ways of doing this: > > 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. > > 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. > > 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. > > I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensate for this. > > Interested to hear if anyone else... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28075 From kbarrett at openjdk.org Tue Feb 3 06:15:36 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 3 Feb 2026 06:15:36 GMT Subject: RFR: 8332189: Enable -Wzero-as-null-pointer-constant for gcc/clang Message-ID: Please review this change which enables `-Wzero-as-null-pointer-constant` warnings in HotSpot code when building with gcc or clang. There are three parts to this change. The first part augments the warning flags setup to support adding warning options that are only applied to HotSpot, rather than the JDK as a whole. There was previously some unused and possibly incomplete support for this when using gcc. Note that the Windows/Visual Studio support hasn't been tested much, and I think might not be working yet. I'm going to investigate that further in followup work. The second part enables `-Wzero-as-null-pointer-constant` for HotSpot code. This follows the guidance to avoid such in the HotSpot Style Guide. The third part removes a note in the HotSpot Style Guide about lingering uses of literal 0 as a null pointer constant. Those have been removed, and this change will block backsliding. Testing: mach5 tier1, GHA Sanity tests Integration of this change needs to wait for JDK-8376758. ------------- Commit messages: - remove obsolete note from style guide - enable -Wzero-as-null-pointer-constant for VM with gcc/clang - support hotspot-specific warnings Changes: https://git.openjdk.org/jdk/pull/29497/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29497&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332189 Stats: 40 lines in 3 files changed: 14 ins; 13 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/29497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29497/head:pull/29497 PR: https://git.openjdk.org/jdk/pull/29497 From dholmes at openjdk.org Tue Feb 3 06:34:02 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 3 Feb 2026 06:34:02 GMT Subject: RFR: 8332189: Enable -Wzero-as-null-pointer-constant for gcc/clang In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 00:16:54 GMT, Kim Barrett wrote: > Please review this change which enables `-Wzero-as-null-pointer-constant` > warnings in HotSpot code when building with gcc or clang. > > There are three parts to this change. > > The first part augments the warning flags setup to support adding warning > options that are only applied to HotSpot, rather than the JDK as a whole. > There was previously some unused and possibly incomplete support for this when > using gcc. Note that the Windows/Visual Studio support hasn't been tested > much, and I think might not be working yet. I'm going to investigate that > further in followup work. > > The second part enables `-Wzero-as-null-pointer-constant` for HotSpot code. > This follows the guidance to avoid such in the HotSpot Style Guide. > > The third part removes a note in the HotSpot Style Guide about lingering uses > of literal 0 as a null pointer constant. Those have been removed, and this > change will block backsliding. > > Testing: mach5 tier1, GHA Sanity tests > > Integration of this change needs to wait for JDK-8376758. Looks reasonable to me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29497#pullrequestreview-3743249921 From kbarrett at openjdk.org Tue Feb 3 07:25:10 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 3 Feb 2026 07:25:10 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base In-Reply-To: References: Message-ID: On Mon, 2 Feb 2026 12:45:50 GMT, Leo Korinth wrote: > Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. > > My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. > > With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. > > This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. > > The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` > `module_file2.cpp_CXXFLAGS+=-Wconversion` > > this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > > (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) There is some overlap in purpose between the build system changes here and those in my proposed change for JDK-8332189 (https://github.com/openjdk/jdk/pull/29497). While this change is more general purpose, it's not obvious to me that it would actually get applied anywhere other than to HotSpot. Being selective about the scope for adding options has both good and bad points. That applies to both approaches. My feeling is the bad outweighs the good here. I don't think I like the idea of having ghettos within HotSpot where different warning options are applied. We already have some of that with per-file disabling of warning, which we don't seem to be making much progress on reducing, even for HotSpot. I've not made any attempt to seriously review the new infrastructure here. I'd prefer to leave that to people with a better understanding of makefile programming and of our build system. make/autoconf/flags-cflags.m4 line 238: > 236: DISABLED_WARNINGS="$DISABLED_WARNINGS psabi" > 237: fi > 238: CFLAGS_CONVERSION_WARNINGS="-Wconversion" As I said in [JDK-8135181](https://bugs.openjdk.org/browse/JDK-8135181) think gcc's `-Wconversion` does too much, and we should for now restrict to conversions between integer types. So also need `-Wno-float-conversion`. make/autoconf/flags-cflags.m4 line 254: > 252: # false positives. > 253: DISABLED_WARNINGS="unknown-warning-option unused-parameter" > 254: CFLAGS_CONVERSION_WARNINGS="-Wconversion -Wno-sign-conversion" For clang I think we should instead use `-Wimplicit-int-conversion`, again to restrict to conversions between integer types for now. make/common/MakeBase.gmk line 173: > 171: unquoteAppendIndex = $(call unQuote,$(word $2,$(subst $(appendQ),$(SPACE),$1))) > 172: > 173: # $(call requrseFiles,dir) -> header.hpp file1.cpp file2.cpp What is "requrse"? I suspect a (consistent) misspelling of something? make/hotspot/lib/CompileJvm.gmk line 192: > 190: abstract_vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ > 191: arguments.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ > 192: $(call overrideFlags,$(TOPDIR)/src/hotspot/share/gc/g1,g1ConcurrentMark.cpp,_CXXFLAGS,$(CFLAGS_CONVERSION_WARNINGS)), \ `overrideFlags` seems like the wrong name for this? Isn't it _extending_ the flags? ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29523#pullrequestreview-3743225824 PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2757406925 PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2757411919 PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2757451590 PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2757436874 From kbarrett at openjdk.org Tue Feb 3 07:30:02 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 3 Feb 2026 07:30:02 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base In-Reply-To: References: Message-ID: <2vaTUEzkqhMV-mMnV6pzqAmaRzkJ1C8mATgaPx58Vyg=.05a4756f-2f0a-43ea-bd63-4c626445e5a6@github.com> On Mon, 2 Feb 2026 12:45:50 GMT, Leo Korinth wrote: > Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. > > My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. > > With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. > > This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. > > The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` > `module_file2.cpp_CXXFLAGS+=-Wconversion` > > this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > > (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) make/hotspot/lib/CompileJvm.gmk line 192: > 190: abstract_vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ > 191: arguments.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ > 192: $(call overrideFlags,$(TOPDIR)/src/hotspot/share/gc/g1,g1ConcurrentMark.cpp,_CXXFLAGS,$(CFLAGS_CONVERSION_WARNINGS)), \ Does this new mechanism support multiple mappings of source trees to warning options? If not, this seems too restrictive. But if so, then my earlier comment about warning ghettos becomes even more of a concern. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2757605647 From jlahoda at openjdk.org Tue Feb 3 09:05:13 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 3 Feb 2026 09:05:13 GMT Subject: Integrated: 8376585: bin/update_copyright_year.sh could allow updating a specified list of files In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 14:18:43 GMT, Jan Lahoda wrote: > There's a script to update copyright years for all files inside changesets in a given branch: > bin/update_copyright_year.sh > > Unfortunately, this is not always ideal for development branches: development branches may contain changes to files that are reverted to the original state later in that branch. As commits inside development branches are squashed at the end, these files are not updated in the final commits, and the copyright headers should not be updated. > > My proposal here is to augment bin/update_copyright_year.sh with an ability to update the years for a given list of files. The list of files is read from stdin. Then one can use a command line like: > > $ git diff upstream/master... | lsdiff | cut -d '/' -f 2- | bash bin/update_copyright_year.sh -m > > To update the years for all files really modified on a given branch. > > I am not an expert on shell/bash, so it is quite possible there are some mistakes here. > > What do you think? Thanks! This pull request has now been integrated. Changeset: 5fec0f32 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/5fec0f3287a64aa56e04ad7c0222dca49a0992e0 Stats: 123 lines in 1 file changed: 46 ins; 23 del; 54 mod 8376585: bin/update_copyright_year.sh could allow updating a specified list of files Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/29467 From azafari at openjdk.org Tue Feb 3 10:49:32 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 3 Feb 2026 10:49:32 GMT Subject: RFR: 8332189: Enable -Wzero-as-null-pointer-constant for gcc/clang In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 00:16:54 GMT, Kim Barrett wrote: > Please review this change which enables `-Wzero-as-null-pointer-constant` > warnings in HotSpot code when building with gcc or clang. > > There are three parts to this change. > > The first part augments the warning flags setup to support adding warning > options that are only applied to HotSpot, rather than the JDK as a whole. > There was previously some unused and possibly incomplete support for this when > using gcc. Note that the Windows/Visual Studio support hasn't been tested > much, and I think might not be working yet. I'm going to investigate that > further in followup work. > > The second part enables `-Wzero-as-null-pointer-constant` for HotSpot code. > This follows the guidance to avoid such in the HotSpot Style Guide. > > The third part removes a note in the HotSpot Style Guide about lingering uses > of literal 0 as a null pointer constant. Those have been removed, and this > change will block backsliding. > > Testing: mach5 tier1, GHA Sanity tests > > Integration of this change needs to wait for JDK-8376758. Thanks for this, Kim! Copyright year is to be updated, IMHO. ------------- PR Review: https://git.openjdk.org/jdk/pull/29497#pullrequestreview-3744538574 From mcimadamore at openjdk.org Tue Feb 3 11:11:18 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 3 Feb 2026 11:11:18 GMT Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16] In-Reply-To: References:

Message-ID: On Wed, 28 Jan 2026 16:27:54 GMT, Jan Lahoda wrote: >> Consider code like: >> >> package test; >> public class Test { >> private int test(Root r) { >> return switch (r) { >> case Root(R2(R1 _), R2(R1 _)) -> 0; >> case Root(R2(R1 _), R2(R2 _)) -> 0; >> case Root(R2(R2 _), R2(R1 _)) -> 0; >> }; >> } >> sealed interface Base {} >> record R1() implements Base {} >> record R2(Base b1) implements Base {} >> record Root(R2 b2, R2 b3) {} >> } >> ``` >> >> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful: >> >> $ javac test/Test.java >> .../test/Test.java:4: error: the switch expression does not cover all possible input values >> return switch (r) { >> ^ >> 1 error >> >> >> The goal of this PR is to improve the error, at least in some cases to something along these lines: >> >> $ javac test/Test.java >> .../test/Test.java:4: error: the switch expression does not cover all possible input values >> return switch (r) { >> ^ >> missing patterns: >> Root(R2(R2 _), R2(R2 _)) >> 1 error >> >> >> The (very simplified) way it works in a recursive (or induction) way: >> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch. >> - for a current missing pattern, try to enhance it: >> - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed. >> - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed. >> >> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process. >> >> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now. >> >> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=`. >> >> There's also an open possibility for select tools to delay the more detailed computation to some late... > > Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: > > - Updating copyright headers. > - Making the skipping of base checks more clear. > - Reflecting review feedback - cleanup. The latest iteration looks solid. Ship it! ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27256#pullrequestreview-3744633936 From mcimadamore at openjdk.org Tue Feb 3 11:11:20 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 3 Feb 2026 11:11:20 GMT Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16] In-Reply-To: References:

Message-ID: On Wed, 28 Jan 2026 18:48:58 GMT, Jan Lahoda wrote: >> test/langtools/tools/javac/patterns/ExhaustivenessConvenientErrors.java line 333: >> >>> 331: case Root(R2 _, R2(R1 _, R2 _), R2(R1 _, R1 _)) -> 0; >>> 332: case Root(R2 _, R2(R1 _, R2 _), R2(R1 _, R2 _)) -> 0; >>> 333: // case Root(R2 _, R2(R1 _, R2 _), R2(R2 _, R1 _)) -> 0; >> >> it could be confusing to have commented code in a test, I guess probably to just remove the commented code? > > These commented-out cases are the ones that are missing from the switch to be exhaustive. I kept them there intentionally, so see what the user might have missed, so that it can be compared with what javac reports. I can add comments to them if desired. I'm ok with these comments -- I'm a bit less ok with the ones that say "this might be better in this form" -- either we file these case as follow up bugs, or we might as well remove the comments, as I don't think a comment in a test is the best way to track issues/further improvements ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2758531330 From vromero at openjdk.org Tue Feb 3 13:58:24 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 3 Feb 2026 13:58:24 GMT Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16] In-Reply-To: References:

Message-ID: On Wed, 28 Jan 2026 16:27:54 GMT, Jan Lahoda wrote: >> Consider code like: >> >> package test; >> public class Test { >> private int test(Root r) { >> return switch (r) { >> case Root(R2(R1 _), R2(R1 _)) -> 0; >> case Root(R2(R1 _), R2(R2 _)) -> 0; >> case Root(R2(R2 _), R2(R1 _)) -> 0; >> }; >> } >> sealed interface Base {} >> record R1() implements Base {} >> record R2(Base b1) implements Base {} >> record Root(R2 b2, R2 b3) {} >> } >> ``` >> >> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful: >> >> $ javac test/Test.java >> .../test/Test.java:4: error: the switch expression does not cover all possible input values >> return switch (r) { >> ^ >> 1 error >> >> >> The goal of this PR is to improve the error, at least in some cases to something along these lines: >> >> $ javac test/Test.java >> .../test/Test.java:4: error: the switch expression does not cover all possible input values >> return switch (r) { >> ^ >> missing patterns: >> Root(R2(R2 _), R2(R2 _)) >> 1 error >> >> >> The (very simplified) way it works in a recursive (or induction) way: >> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch. >> - for a current missing pattern, try to enhance it: >> - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed. >> - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed. >> >> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process. >> >> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now. >> >> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=`. >> >> There's also an open possibility for select tools to delay the more detailed computation to some late... > > Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: > > - Updating copyright headers. > - Making the skipping of base checks more clear. > - Reflecting review feedback - cleanup. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 656: > 654: } > 655: if (covered) { > 656: PatternDescription pd = new BindingPattern(rpOne.recordType, -1, Set.of(pattern)); shouldn't this `-1` be: `NO_BASE_CHECKS_COUNTING`? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 744: > 742: > 743: public BindingPattern(Type type) { > 744: this(type, -1, Set.of()); same here -1 -> NO_BASE_CHECKS_COUNTING ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2759213147 PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2759215854 From lkorinth at openjdk.org Tue Feb 3 14:15:06 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 3 Feb 2026 14:15:06 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base In-Reply-To: References:

Message-ID: <18H4ai1UOKt2fwwUim9P39x2Z8j3AGYYMCDthdh_HKY=.4368a424-87fc-4fb7-8650-d74cb97b878e@github.com> On Tue, 3 Feb 2026 06:24:04 GMT, Kim Barrett wrote: >> Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. >> >> My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. >> >> With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. >> >> This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. >> >> The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` >> `module_file2.cpp_CXXFLAGS+=-Wconversion` >> >> this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> >> (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) > > make/autoconf/flags-cflags.m4 line 238: > >> 236: DISABLED_WARNINGS="$DISABLED_WARNINGS psabi" >> 237: fi >> 238: CFLAGS_CONVERSION_WARNINGS="-Wconversion" > > As I said in [JDK-8135181](https://bugs.openjdk.org/browse/JDK-8135181) think gcc's > `-Wconversion` does too much, and we should for now restrict to conversions between > integer types. So also need `-Wno-float-conversion`. I can change that. > make/autoconf/flags-cflags.m4 line 254: > >> 252: # false positives. >> 253: DISABLED_WARNINGS="unknown-warning-option unused-parameter" >> 254: CFLAGS_CONVERSION_WARNINGS="-Wconversion -Wno-sign-conversion" > > For clang I think we should instead use `-Wimplicit-int-conversion`, again to restrict > to conversions between integer types for now. I can change that. > make/hotspot/lib/CompileJvm.gmk line 192: > >> 190: abstract_vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >> 191: arguments.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >> 192: $(call overrideFlags,$(TOPDIR)/src/hotspot/share/gc/g1,g1ConcurrentMark.cpp,_CXXFLAGS,$(CFLAGS_CONVERSION_WARNINGS)), \ > > `overrideFlags` seems like the wrong name for this? Isn't it _extending_ the flags? I think both extending and appending is better, I will use your suggestion "extending" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2759280717 PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2759285231 PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2759292983 From lkorinth at openjdk.org Tue Feb 3 14:18:15 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 3 Feb 2026 14:18:15 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 06:39:55 GMT, Kim Barrett wrote: >> Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. >> >> My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. >> >> With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. >> >> This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. >> >> The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` >> `module_file2.cpp_CXXFLAGS+=-Wconversion` >> >> this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> >> (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) > > make/common/MakeBase.gmk line 173: > >> 171: unquoteAppendIndex = $(call unQuote,$(word $2,$(subst $(appendQ),$(SPACE),$1))) >> 172: >> 173: # $(call requrseFiles,dir) -> header.hpp file1.cpp file2.cpp > > What is "requrse"? I suspect a (consistent) misspelling of something? Hehe that was a bad one! recurse, will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2759314135 From lkorinth at openjdk.org Tue Feb 3 14:21:27 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 3 Feb 2026 14:21:27 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base In-Reply-To: <2vaTUEzkqhMV-mMnV6pzqAmaRzkJ1C8mATgaPx58Vyg=.05a4756f-2f0a-43ea-bd63-4c626445e5a6@github.com> References: <2vaTUEzkqhMV-mMnV6pzqAmaRzkJ1C8mATgaPx58Vyg=.05a4756f-2f0a-43ea-bd63-4c626445e5a6@github.com> Message-ID: On Tue, 3 Feb 2026 07:26:57 GMT, Kim Barrett wrote: >> Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. >> >> My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. >> >> With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. >> >> This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. >> >> The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` >> `module_file2.cpp_CXXFLAGS+=-Wconversion` >> >> this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> >> (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) > > make/hotspot/lib/CompileJvm.gmk line 192: > >> 190: abstract_vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >> 191: arguments.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >> 192: $(call overrideFlags,$(TOPDIR)/src/hotspot/share/gc/g1,g1ConcurrentMark.cpp,_CXXFLAGS,$(CFLAGS_CONVERSION_WARNINGS)), \ > > Does this new mechanism support multiple mappings of source trees to warning > options? If not, this seems too restrictive. But if so, then my earlier > comment about warning ghettos becomes even more of a concern. Multiple, and overlapping regions, with different source directories and different filters. I fully support warning ghettos, I see it as a fantastic opportunity! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2759329187 From jlahoda at openjdk.org Tue Feb 3 14:39:13 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 3 Feb 2026 14:39:13 GMT Subject: RFR: 8367530: The exhaustiveness errors could be improved [v17] In-Reply-To: References: Message-ID: > Consider code like: > > package test; > public class Test { > private int test(Root r) { > return switch (r) { > case Root(R2(R1 _), R2(R1 _)) -> 0; > case Root(R2(R1 _), R2(R2 _)) -> 0; > case Root(R2(R2 _), R2(R1 _)) -> 0; > }; > } > sealed interface Base {} > record R1() implements Base {} > record R2(Base b1) implements Base {} > record Root(R2 b2, R2 b3) {} > } > ``` > > This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful: > > $ javac test/Test.java > .../test/Test.java:4: error: the switch expression does not cover all possible input values > return switch (r) { > ^ > 1 error > > > The goal of this PR is to improve the error, at least in some cases to something along these lines: > > $ javac test/Test.java > .../test/Test.java:4: error: the switch expression does not cover all possible input values > return switch (r) { > ^ > missing patterns: > Root(R2(R2 _), R2(R2 _)) > 1 error > > > The (very simplified) way it works in a recursive (or induction) way: > - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch. > - for a current missing pattern, try to enhance it: > - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed. > - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed. > > This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process. > > There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now. > > Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=`. > > There's also an open possibility for select tools to delay the more detailed computation to some later time, although that would need to be tried and evaluated. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Cleanup: permittedSubtypes in BindingPattern is not needed anymore. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27256/files - new: https://git.openjdk.org/jdk/pull/27256/files/539760bc..17e65e43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=15-16 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27256/head:pull/27256 PR: https://git.openjdk.org/jdk/pull/27256 From jlahoda at openjdk.org Tue Feb 3 14:39:16 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 3 Feb 2026 14:39:16 GMT Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16] In-Reply-To: References:

Message-ID: <1xivIHAw1s0prGQT4Ie9Etr2fww-96ZXd1ZBiQDDruE=.15700758-4edd-4e2e-8bd5-03cee49a9703@github.com> On Tue, 3 Feb 2026 13:55:20 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: >> >> - Updating copyright headers. >> - Making the skipping of base checks more clear. >> - Reflecting review feedback - cleanup. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 656: > >> 654: } >> 655: if (covered) { >> 656: PatternDescription pd = new BindingPattern(rpOne.recordType, -1, Set.of(pattern)); > > shouldn't this `-1` be: `NO_BASE_CHECKS_COUNTING`? The `-1` here was the number of permitted subtypes, so not quite `NO_BASE_CHECKS_COUNTING`. But, looking at it, the component is not needed anymore, so removed. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2759406854 From erikj at openjdk.org Tue Feb 3 14:56:47 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Feb 2026 14:56:47 GMT Subject: RFR: 8332189: Enable -Wzero-as-null-pointer-constant for gcc/clang In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 00:16:54 GMT, Kim Barrett wrote: > Please review this change which enables `-Wzero-as-null-pointer-constant` > warnings in HotSpot code when building with gcc or clang. > > There are three parts to this change. > > The first part augments the warning flags setup to support adding warning > options that are only applied to HotSpot, rather than the JDK as a whole. > There was previously some unused and possibly incomplete support for this when > using gcc. Note that the Windows/Visual Studio support hasn't been tested > much, and I think might not be working yet. I'm going to investigate that > further in followup work. > > The second part enables `-Wzero-as-null-pointer-constant` for HotSpot code. > This follows the guidance to avoid such in the HotSpot Style Guide. > > The third part removes a note in the HotSpot Style Guide about lingering uses > of literal 0 as a null pointer constant. Those have been removed, and this > change will block backsliding. > > Testing: mach5 tier1, GHA Sanity tests > > Integration of this change needs to wait for JDK-8376758. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29497#pullrequestreview-3745761404 From vromero at openjdk.org Tue Feb 3 15:23:38 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 3 Feb 2026 15:23:38 GMT Subject: RFR: 8367530: The exhaustiveness errors could be improved [v17] In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 14:39:13 GMT, Jan Lahoda wrote: >> Consider code like: >> >> package test; >> public class Test { >> private int test(Root r) { >> return switch (r) { >> case Root(R2(R1 _), R2(R1 _)) -> 0; >> case Root(R2(R1 _), R2(R2 _)) -> 0; >> case Root(R2(R2 _), R2(R1 _)) -> 0; >> }; >> } >> sealed interface Base {} >> record R1() implements Base {} >> record R2(Base b1) implements Base {} >> record Root(R2 b2, R2 b3) {} >> } >> ``` >> >> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful: >> >> $ javac test/Test.java >> .../test/Test.java:4: error: the switch expression does not cover all possible input values >> return switch (r) { >> ^ >> 1 error >> >> >> The goal of this PR is to improve the error, at least in some cases to something along these lines: >> >> $ javac test/Test.java >> .../test/Test.java:4: error: the switch expression does not cover all possible input values >> return switch (r) { >> ^ >> missing patterns: >> Root(R2(R2 _), R2(R2 _)) >> 1 error >> >> >> The (very simplified) way it works in a recursive (or induction) way: >> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch. >> - for a current missing pattern, try to enhance it: >> - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed. >> - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed. >> >> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process. >> >> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now. >> >> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=`. >> >> There's also an open possibility for select tools to delay the more detailed computation to some late... > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup: permittedSubtypes in BindingPattern is not needed anymore. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27256#pullrequestreview-3745904969 From vromero at openjdk.org Tue Feb 3 15:23:41 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 3 Feb 2026 15:23:41 GMT Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16] In-Reply-To: <1xivIHAw1s0prGQT4Ie9Etr2fww-96ZXd1ZBiQDDruE=.15700758-4edd-4e2e-8bd5-03cee49a9703@github.com> References:

<1xivIHAw1s0prGQT4Ie9Etr2fww-96ZXd1ZBiQDDruE=.15700758-4edd-4e2e-8bd5-03cee49a9703@github.com> Message-ID: On Tue, 3 Feb 2026 14:35:44 GMT, Jan Lahoda wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 656: >> >>> 654: } >>> 655: if (covered) { >>> 656: PatternDescription pd = new BindingPattern(rpOne.recordType, -1, Set.of(pattern)); >> >> shouldn't this `-1` be: `NO_BASE_CHECKS_COUNTING`? > > The `-1` here was the number of permitted subtypes, so not quite `NO_BASE_CHECKS_COUNTING`. But, looking at it, the component is not needed anymore, so removed. Thanks! oh I see, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2759617378 From lkorinth at openjdk.org Tue Feb 3 15:46:02 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 3 Feb 2026 15:46:02 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v2] In-Reply-To: References: Message-ID: > Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. > > My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. > > With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. > > This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. > > The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` > `module_file2.cpp_CXXFLAGS+=-Wconversion` > > this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > > (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: Changes after comments from Erik and Kim ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29523/files - new: https://git.openjdk.org/jdk/pull/29523/files/150b2e3c..7964670b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=00-01 Stats: 30 lines in 3 files changed: 21 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29523.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29523/head:pull/29523 PR: https://git.openjdk.org/jdk/pull/29523 From lkorinth at openjdk.org Tue Feb 3 16:22:08 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 3 Feb 2026 16:22:08 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v2] In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 07:22:27 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes after comments from Erik and Kim > > There is some overlap in purpose between the build system changes here and > those in my proposed change for JDK-8332189 (https://github.com/openjdk/jdk/pull/29497). > While this change is more general purpose, it's not obvious to me that it > would actually get applied anywhere other than to HotSpot. Being selective > about the scope for adding options has both good and bad points. That applies > to both approaches. My feeling is the bad outweighs the good here. I don't > think I like the idea of having ghettos within HotSpot where different warning > options are applied. We already have some of that with per-file disabling of > warning, which we don't seem to be making much progress on reducing, even for > HotSpot. > > I've not made any attempt to seriously review the new infrastructure here. I'd > prefer to leave that to people with a better understanding of makefile > programming and of our build system. I am not opposing your (@kimbarrett ) changes to warning flags and that is a great option if you can fix changes in all of hotspot. My changes are great when incrementally hardening the flags. I think my feature is really needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29523#issuecomment-3842281488 From erikj at openjdk.org Tue Feb 3 16:46:50 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Feb 2026 16:46:50 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v2] In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 15:46:02 GMT, Leo Korinth wrote: >> Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. >> >> My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. >> >> With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. >> >> This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. >> >> The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` >> `module_file2.cpp_CXXFLAGS+=-Wconversion` >> >> this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> >> (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > Changes after comments from Erik and Kim This looks ok from a build perspective. The question about supporting "warning ghettos" in Hotspot isn't really something I want to get into, so will leave that for other reviewers, so if you can reach agreement there, then this is ok with me. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29523#pullrequestreview-3746358521 From aivanov at openjdk.org Tue Feb 3 20:37:48 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 3 Feb 2026 20:37:48 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt wrote: > This to support linux headless mode without X11. E.g. A headless server. I tested it in a live Ubuntu image. I installed all the dependencies except for X11 headers. The regular run of `configure` failed for me complaining about the missing X11 headers. When I passed the `--enable-headless-only` option to `configure`, it succeeded, and the build succeeded. I ran headless AWT tests, and all the tests passed. The fix for [JDK-8255785](https://bugs.openjdk.org/browse/JDK-8255785) that enabled building headless JDK without the X11 headers was reverted by [JDK-8258465](https://bugs.openjdk.org/browse/JDK-8258465) because there was a dependency on definition of the rectangle structure. The fix proposed in this PR removes that dependency by providing an alternative definition, the same one that's already used on macOS. Thus, this fix also resolves [JDK-8273258](https://bugs.openjdk.org/browse/JDK-8273258). ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28310#pullrequestreview-3747431493 From aivanov at openjdk.org Tue Feb 3 20:40:12 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 3 Feb 2026 20:40:12 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt wrote: > This to support linux headless mode without X11. E.g. A headless server. I also ran the clientlibs tests in Oracle CI. There were a few failures, they were unrelated to this fix. To play it safe, today I merged `master` into my local branch with this fix and submitted a new test job. The test job hasn't completed yet, but there are no failures so far. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3843529266 From duke at openjdk.org Tue Feb 3 21:21:14 2026 From: duke at openjdk.org (Thomas Devoogdt) Date: Tue, 3 Feb 2026 21:21:14 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt wrote: > This to support linux headless mode without X11. E.g. A headless server. Thanks for the reviews and tests. I assume that merging goes automatically now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3843732377 From aivanov at openjdk.org Tue Feb 3 21:29:38 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 3 Feb 2026 21:29:38 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 21:18:00 GMT, Thomas Devoogdt wrote: > Thanks for the reviews and tests. I assume that merging goes automatically now? No, you have to issue the [`/integrate` command](https://wiki.openjdk.org/spaces/SKARA/pages/56524908/Pull+Request+Commands#PullRequestCommands-/integrate). Then a [*Committer*](https://openjdk.org/bylaws#committer) will use the [`/sponsor` command](https://wiki.openjdk.org/spaces/SKARA/pages/56524908/Pull+Request+Commands#PullRequestCommands-/sponsor) to integrate the changeset. I'll happily sponsor once the test job finishes. I'll also allow some time for Phil to approve this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3843766391 From duke at openjdk.org Tue Feb 3 21:33:59 2026 From: duke at openjdk.org (duke) Date: Tue, 3 Feb 2026 21:33:59 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt wrote: > This to support linux headless mode without X11. E.g. A headless server. @ThomasDevoogdt Your change (at version a5292aa123dfedd610bb7019b1645875a82b6ca7) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3843781354 From jwilhelm at openjdk.org Tue Feb 3 22:24:36 2026 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 3 Feb 2026 22:24:36 GMT Subject: [jdk26] Integrated: 8376035: Remove EA from the JDK 26 version string with first RC promotion In-Reply-To: References: Message-ID: <93iLErYFqPmrWmpdnzcpJxZkypGHAoUEmocYHnmbBmw=.0cbc9ed7-51c2-4681-8741-750119a9c4a0@github.com> On Tue, 27 Jan 2026 15:50:31 GMT, Jesper Wilhelmsson wrote: > Removed EA This pull request has now been integrated. Changeset: dc46cc64 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/dc46cc6469d8fcd18d2702add060b5f2026dad3c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8376035: Remove EA from the JDK 26 version string with first RC promotion Reviewed-by: mikael, iris, erikj ------------- PR: https://git.openjdk.org/jdk/pull/29453 From bpb at openjdk.org Wed Feb 4 02:00:46 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 4 Feb 2026 02:00:46 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v20] In-Reply-To: References: Message-ID: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter 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 - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - ... and 10 more: https://git.openjdk.org/jdk/compare/e51ccef9...84337f02 ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=19 Stats: 1539 lines in 92 files changed: 774 ins; 668 del; 97 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From duke at openjdk.org Wed Feb 4 06:52:38 2026 From: duke at openjdk.org (Thomas Devoogdt) Date: Wed, 4 Feb 2026 06:52:38 GMT Subject: Integrated: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt wrote: > This to support linux headless mode without X11. E.g. A headless server. This pull request has now been integrated. Changeset: 1069cceb Author: Thomas Devoogdt Committer: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/1069ccebcc32e02055985e2babfa2986a2e295ca Stats: 30 lines in 5 files changed: 14 ins; 5 del; 11 mod 8376684: Compile OpenJDK in headless mode without required X11 libraries Reviewed-by: erikj, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/28310 From duke at openjdk.org Wed Feb 4 07:08:07 2026 From: duke at openjdk.org (Thomas Devoogdt) Date: Wed, 4 Feb 2026 07:08:07 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: References:

Message-ID: <5Vj1Hpwga_JuLq8z4OpkIVrNN3_HC92t2xYB7QFtDNo=.2fdf6efb-4353-4322-8e74-6349e8985577@github.com> On Thu, 29 Jan 2026 09:56:13 GMT, Thomas Stuefe wrote: >> This to support linux headless mode without X11. E.g. A headless server. > > Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in. > > But I am no expert in this area; @magicus and @prrace should look at this. > > If this gets pushed, downporting it to LTSes is possible. @tstuefe What is the procedure to get this back ported to the LTS branches? Just open PRs there with a reference to this one? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3845731350 From jlahoda at openjdk.org Wed Feb 4 08:41:07 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 4 Feb 2026 08:41:07 GMT Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16] In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 11:07:40 GMT, Maurizio Cimadamore wrote: >> These commented-out cases are the ones that are missing from the switch to be exhaustive. I kept them there intentionally, so see what the user might have missed, so that it can be compared with what javac reports. I can add comments to them if desired. > > I'm ok with these comments -- I'm a bit less ok with the ones that say "this might be better in this form" -- either we file these case as follow up bugs, or we might as well remove the comments, as I don't think a comment in a test is the best way to track issues/further improvements I've filled: https://bugs.openjdk.org/browse/JDK-8377147 for me, the purpose of the comment here is to make the situation clearer for the reader of the test. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2762826915 From jlahoda at openjdk.org Wed Feb 4 11:07:16 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 4 Feb 2026 11:07:16 GMT Subject: Integrated: 8367530: The exhaustiveness errors could be improved In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 11:45:33 GMT, Jan Lahoda wrote: > Consider code like: > > package test; > public class Test { > private int test(Root r) { > return switch (r) { > case Root(R2(R1 _), R2(R1 _)) -> 0; > case Root(R2(R1 _), R2(R2 _)) -> 0; > case Root(R2(R2 _), R2(R1 _)) -> 0; > }; > } > sealed interface Base {} > record R1() implements Base {} > record R2(Base b1) implements Base {} > record Root(R2 b2, R2 b3) {} > } > ``` > > This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful: > > $ javac test/Test.java > .../test/Test.java:4: error: the switch expression does not cover all possible input values > return switch (r) { > ^ > 1 error > > > The goal of this PR is to improve the error, at least in some cases to something along these lines: > > $ javac test/Test.java > .../test/Test.java:4: error: the switch expression does not cover all possible input values > return switch (r) { > ^ > missing patterns: > Root(R2(R2 _), R2(R2 _)) > 1 error > > > The (very simplified) way it works in a recursive (or induction) way: > - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch. > - for a current missing pattern, try to enhance it: > - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed. > - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed. > > This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process. > > There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now. > > Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=`. > > There's also an open possibility for select tools to delay the more detailed computation to some later time, although that would need to be tried and evaluated. This pull request has now been integrated. Changeset: 84e8787d Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/84e8787d1fdfe2d92f8b2c9b959651d8d63be91b Stats: 1498 lines in 16 files changed: 1399 ins; 49 del; 50 mod 8367530: The exhaustiveness errors could be improved Reviewed-by: vromero, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/27256 From aivanov at openjdk.org Wed Feb 4 12:01:27 2026 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 4 Feb 2026 12:01:27 GMT Subject: RFR: 8376684: Compile OpenJDK in headless mode without required X11 libraries In-Reply-To: <5Vj1Hpwga_JuLq8z4OpkIVrNN3_HC92t2xYB7QFtDNo=.2fdf6efb-4353-4322-8e74-6349e8985577@github.com> References:

<5Vj1Hpwga_JuLq8z4OpkIVrNN3_HC92t2xYB7QFtDNo=.2fdf6efb-4353-4322-8e74-6349e8985577@github.com> Message-ID: On Wed, 4 Feb 2026 07:05:27 GMT, Thomas Devoogdt wrote: > What is the procedure to get this back ported to the LTS branches? Just open PRs there with a reference to this one? See the guidelines for [Backporting](https://openjdk.org/guide/#backporting), and in particular [Requesting approvals for backports](https://openjdk.org/guide/#requesting-approvals-for-backports). Essentially, you create backport PRs for LTS releases and request approvals. You can look for examples at the [*jdk-updates-dev* mailing list](https://mail.openjdk.org/pipermail/jdk-updates-dev/). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3847022323 From azafari at openjdk.org Wed Feb 4 12:27:55 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 4 Feb 2026 12:27:55 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v2] In-Reply-To: References:

Message-ID: On Thu, 29 Jan 2026 09:56:13 GMT, Thomas Stuefe wrote: >> This to support linux headless mode without X11. E.g. A headless server. > > Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in. > > But I am no expert in this area; @magicus and @prrace should look at this. > > If this gets pushed, downporting it to LTSes is possible. ahem @tstuefe I was waiting for Alexey to finish testing before adding my approval, did you not see the comments by Alexey ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3848367244 From mbaesken at openjdk.org Thu Feb 5 10:34:24 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 5 Feb 2026 10:34:24 GMT Subject: RFR: 8377231: Build jpackage with SIZE optimization Message-ID: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> We can reduce the size of the jpackage.jmod by using SIZE optimization for the native components on Linux. See SIZE opt. linuxx86_64 gcc13 devkit du -sk images/jdk/jmods/jdk.jpackage.jmod 1292 images/jdk/jmods/jdk.jpackage.jmod linuxppc64le gcc13 devkit du -sk images/jdk/jmods/jdk.jpackage.jmod 1416 images/jdk/jmods/jdk.jpackage.jmod NORMAL opt. linuxx86_64 gcc13 devkit du -sk images/jdk/jmods/jdk.jpackage.jmod 1336 images/jdk/jmods/jdk.jpackage.jmod linuxppc64le gcc13 devkit du -sk images/jdk/jmods/jdk.jpackage.jmod 1460 images/jdk/jmods/jdk.jpackage.jmod ------------- Commit messages: - JDK-8377231 Changes: https://git.openjdk.org/jdk/pull/29585/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29585&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377231 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29585/head:pull/29585 PR: https://git.openjdk.org/jdk/pull/29585 From erikj at openjdk.org Thu Feb 5 16:32:36 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 5 Feb 2026 16:32:36 GMT Subject: RFR: 8377231: Build jpackage with SIZE optimization In-Reply-To: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> References: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> Message-ID: On Thu, 5 Feb 2026 10:26:53 GMT, Matthias Baesken wrote: > We can reduce the size of the jpackage.jmod by using SIZE optimization for the native components on Linux. > See > > > SIZE opt. > linuxx86_64 gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1292 images/jdk/jmods/jdk.jpackage.jmod > > linuxppc64le gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1416 images/jdk/jmods/jdk.jpackage.jmod > > > NORMAL opt. > linuxx86_64 gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1336 images/jdk/jmods/jdk.jpackage.jmod > > linuxppc64le gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1460 images/jdk/jmods/jdk.jpackage.jmod Seems ok with me, but someone from the component team should weigh in as well. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29585#pullrequestreview-3758180625 From naoto at openjdk.org Thu Feb 5 17:35:37 2026 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 5 Feb 2026 17:35:37 GMT Subject: RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows (Asia/Calcutta) Message-ID: Fixing the Windows default time zones returned from `TimeZone.getDefault()` for some regions. On Windows, it uses their own regions for time zones that aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for those regions. Since it is hard to provide an automated test, as it involves the modification of the Windows' default time zone, regression test is not provided. Instead the fix is manually confirmed using the JIRA issue's example. Since this is a change in behavior, I will file a corresponding CSR/RN. Here is the diff of the generated `conf/tzmappings` for reference: @@ -13,7 +13,7 @@ Arabian Standard Time:ZZ:Etc/GMT-4: Arabian Standard Time:001:Asia/Dubai: Arabic Standard Time:001:Asia/Baghdad: -Argentina Standard Time:001:America/Buenos_Aires: +Argentina Standard Time:001:America/Argentina/Buenos_Aires: Astrakhan Standard Time:001:Europe/Astrakhan: Atlantic Standard Time:BM:Atlantic/Bermuda: Atlantic Standard Time:GL:America/Thule: @@ -58,7 +58,7 @@ Central European Standard Time:MK:Europe/Skopje: Central European Standard Time:001:Europe/Warsaw: Central Pacific Standard Time:AQ:Antarctica/Casey: -Central Pacific Standard Time:FM:Pacific/Ponape: +Central Pacific Standard Time:FM:Pacific/Pohnpei: Central Pacific Standard Time:NC:Pacific/Noumea: Central Pacific Standard Time:VU:Pacific/Efate: Central Pacific Standard Time:ZZ:Etc/GMT-11: @@ -75,7 +75,7 @@ Dateline Standard Time:001:Etc/GMT+12: E. Africa Standard Time:AQ:Antarctica/Syowa: E. Africa Standard Time:DJ:Africa/Djibouti: -E. Africa Standard Time:ER:Africa/Asmera: +E. Africa Standard Time:ER:Africa/Asmara: E. Africa Standard Time:ET:Africa/Addis_Ababa: E. Africa Standard Time:KM:Indian/Comoro: E. Africa Standard Time:MG:Indian/Antananarivo: @@ -101,10 +101,10 @@ FLE Standard Time:FI:Europe/Helsinki: FLE Standard Time:LT:Europe/Vilnius: FLE Standard Time:LV:Europe/Riga: -FLE Standard Time:001:Europe/Kiev: +FLE Standard Time:001:Europe/Kyiv: Fiji Standard Time:001:Pacific/Fiji: GMT Standard Time:ES:Atlantic/Canary: -GMT Standard Time:FO:Atlantic/Faeroe: +GMT Standard Time:FO:Atlantic/Faroe: GMT Standard Time:GG:Europe/Guernsey: GMT Standard Time:IE:Europe/Dublin: GMT Standard Time:IM:Europe/Isle_of_Man: @@ -115,7 +115,7 @@ GTB Standard Time:GR:Europe/Athens: GTB Standard Time:001:Europe/Bucharest: Georgian Standard Time:001:Asia/Tbilisi: -Greenland Standard Time:001:America/Godthab: +Greenland Standard Time:001:America/Nuuk: Greenwich Standard Time:BF:Africa/Ouagadougou: Greenwich Standard Time:CI:Africa/Abidjan: Greenwich Standard Time:GH:Africa/Accra: @@ -136,7 +136,7 @@ Hawaiian Standard Time:PF:Pacific/Tahiti: Hawaiian Standard Time:ZZ:Etc/GMT+10: Hawaiian Standard Time:001:Pacific/Honolulu: -India Standard Time:001:Asia/Calcutta: +India Standard Time:001:Asia/Kolkata: Iran Standard Time:001:Asia/Tehran: Israel Standard Time:001:Asia/Jerusalem: Jordan Standard Time:001:Asia/Amman: @@ -161,10 +161,10 @@ Mountain Standard Time:001:America/Denver: Mountain Standard Time (Mexico):001:America/Mazatlan: Myanmar Standard Time:CC:Indian/Cocos: -Myanmar Standard Time:001:Asia/Rangoon: +Myanmar Standard Time:001:Asia/Yangon: N. Central Asia Standard Time:001:Asia/Novosibirsk: Namibia Standard Time:001:Africa/Windhoek: -Nepal Standard Time:001:Asia/Katmandu: +Nepal Standard Time:001:Asia/Kathmandu: New Zealand Standard Time:AQ:Antarctica/McMurdo: New Zealand Standard Time:001:Pacific/Auckland: Newfoundland Standard Time:001:America/St_Johns: @@ -196,7 +196,7 @@ SA Eastern Standard Time:ZZ:Etc/GMT+3: SA Eastern Standard Time:001:America/Cayenne: SA Pacific Standard Time:BR:America/Rio_Branco: -SA Pacific Standard Time:CA:America/Coral_Harbour: +SA Pacific Standard Time:CA:America/Atikokan: SA Pacific Standard Time:EC:America/Guayaquil: SA Pacific Standard Time:JM:America/Jamaica: SA Pacific Standard Time:KY:America/Cayman: @@ -236,7 +236,7 @@ SE Asia Standard Time:ID:Asia/Jakarta: SE Asia Standard Time:KH:Asia/Phnom_Penh: SE Asia Standard Time:LA:Asia/Vientiane: -SE Asia Standard Time:VN:Asia/Saigon: +SE Asia Standard Time:VN:Asia/Ho_Chi_Minh: SE Asia Standard Time:ZZ:Etc/GMT-7: SE Asia Standard Time:001:Asia/Bangkok: Saint Pierre Standard Time:001:America/Miquelon: @@ -279,7 +279,7 @@ Transbaikal Standard Time:001:Asia/Chita: Turkey Standard Time:001:Europe/Istanbul: Turks And Caicos Standard Time:001:America/Grand_Turk: -US Eastern Standard Time:001:America/Indianapolis: +US Eastern Standard Time:001:America/Indiana/Indianapolis: US Mountain Standard Time:CA:America/Creston: US Mountain Standard Time:MX:America/Hermosillo: US Mountain Standard Time:ZZ:Etc/GMT+7: @@ -292,7 +292,7 @@ UTC+12:UM:Pacific/Wake: UTC+12:WF:Pacific/Wallis: UTC+12:001:Etc/GMT-12: -UTC+13:KI:Pacific/Enderbury: +UTC+13:KI:Pacific/Kanton: UTC+13:TK:Pacific/Fakaofo: UTC+13:001:Etc/GMT-13: UTC-02:BR:America/Noronha: @@ -352,7 +352,7 @@ West Asia Standard Time:001:Asia/Tashkent: West Bank Standard Time:001:Asia/Hebron: West Pacific Standard Time:AQ:Antarctica/DumontDUrville: -West Pacific Standard Time:FM:Pacific/Truk: +West Pacific Standard Time:FM:Pacific/Chuuk: West Pacific Standard Time:GU:Pacific/Guam: West Pacific Standard Time:MP:Pacific/Saipan: West Pacific Standard Time:ZZ:Etc/GMT-10: ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/29591/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29591&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377013 Stats: 28 lines in 3 files changed: 23 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29591/head:pull/29591 PR: https://git.openjdk.org/jdk/pull/29591 From mbaesken at openjdk.org Fri Feb 6 07:46:39 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 6 Feb 2026 07:46:39 GMT Subject: RFR: 8377231: Build jpackage with SIZE optimization In-Reply-To: References: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> Message-ID: <0Y7Qf67cIc0x1z-WfTTleQcrwCH1ChRVvRYA6L4kPsg=.1646160c-447d-4b06-bb9c-7cbf2384c5da@github.com> On Thu, 5 Feb 2026 16:30:10 GMT, Erik Joelsson wrote: > Seems ok with me, but someone from the component team should weigh in as well. Thanks for the review ! @alexeysemenyukoracle , wanna have a look ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29585#issuecomment-3858575332 From asemenyuk at openjdk.org Fri Feb 6 10:58:27 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 6 Feb 2026 10:58:27 GMT Subject: RFR: 8377231: Build jpackage with SIZE optimization In-Reply-To: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> References: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> Message-ID: On Thu, 5 Feb 2026 10:26:53 GMT, Matthias Baesken wrote: > We can reduce the size of the jpackage.jmod by using SIZE optimization for the native components on Linux. > See > > > SIZE opt. > linuxx86_64 gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1292 images/jdk/jmods/jdk.jpackage.jmod > > linuxppc64le gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1416 images/jdk/jmods/jdk.jpackage.jmod > > > NORMAL opt. > linuxx86_64 gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1336 images/jdk/jmods/jdk.jpackage.jmod > > linuxppc64le gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1460 images/jdk/jmods/jdk.jpackage.jmod Marked as reviewed by asemenyuk (Reviewer). Looks good! ------------- PR Review: https://git.openjdk.org/jdk/pull/29585#pullrequestreview-3762363267 PR Comment: https://git.openjdk.org/jdk/pull/29585#issuecomment-3859696483 From mbaesken at openjdk.org Fri Feb 6 12:39:09 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 6 Feb 2026 12:39:09 GMT Subject: RFR: 8377231: Build jpackage with SIZE optimization In-Reply-To: <0Y7Qf67cIc0x1z-WfTTleQcrwCH1ChRVvRYA6L4kPsg=.1646160c-447d-4b06-bb9c-7cbf2384c5da@github.com> References: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> <0Y7Qf67cIc0x1z-WfTTleQcrwCH1ChRVvRYA6L4kPsg=.1646160c-447d-4b06-bb9c-7cbf2384c5da@github.com> Message-ID: On Fri, 6 Feb 2026 07:44:17 GMT, Matthias Baesken wrote: > Seems ok with me, but someone from the component team should weigh in as well. Alexey are you from the 'component team' or do we have to wait for another review ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29585#issuecomment-3860201148 From asemenyuk at openjdk.org Fri Feb 6 12:55:48 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 6 Feb 2026 12:55:48 GMT Subject: RFR: 8377231: Build jpackage with SIZE optimization In-Reply-To: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> References: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> Message-ID: On Thu, 5 Feb 2026 10:26:53 GMT, Matthias Baesken wrote: > We can reduce the size of the jpackage.jmod by using SIZE optimization for the native components on Linux. > See > > > SIZE opt. > linuxx86_64 gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1292 images/jdk/jmods/jdk.jpackage.jmod > > linuxppc64le gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1416 images/jdk/jmods/jdk.jpackage.jmod > > > NORMAL opt. > linuxx86_64 gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1336 images/jdk/jmods/jdk.jpackage.jmod > > linuxppc64le gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1460 images/jdk/jmods/jdk.jpackage.jmod Basically, there are two maintainers of jpackage, @sashamatveev and me. Does it make me a 'component team'? ? @kevinrushforth, do we need another reviewer for this PR? Oh, OK. It was fast ?. No problem, I think we are good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29585#issuecomment-3860268004 PR Comment: https://git.openjdk.org/jdk/pull/29585#issuecomment-3860275181 PR Comment: https://git.openjdk.org/jdk/pull/29585#issuecomment-3860284139 From mbaesken at openjdk.org Fri Feb 6 12:55:49 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 6 Feb 2026 12:55:49 GMT Subject: RFR: 8377231: Build jpackage with SIZE optimization In-Reply-To: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> References: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> Message-ID: <5dOYLNfquja528uS9kXaoMCy7kVjbMCUacDO5DDF5qw=.ba402a78-a9a0-4b89-af66-3ff86c93fbba@github.com> On Thu, 5 Feb 2026 10:26:53 GMT, Matthias Baesken wrote: > We can reduce the size of the jpackage.jmod by using SIZE optimization for the native components on Linux. > See > > > SIZE opt. > linuxx86_64 gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1292 images/jdk/jmods/jdk.jpackage.jmod > > linuxppc64le gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1416 images/jdk/jmods/jdk.jpackage.jmod > > > NORMAL opt. > linuxx86_64 gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1336 images/jdk/jmods/jdk.jpackage.jmod > > linuxppc64le gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1460 images/jdk/jmods/jdk.jpackage.jmod Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29585#issuecomment-3860275793 From mbaesken at openjdk.org Fri Feb 6 12:55:51 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 6 Feb 2026 12:55:51 GMT Subject: Integrated: 8377231: Build jpackage with SIZE optimization In-Reply-To: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> References: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> Message-ID: On Thu, 5 Feb 2026 10:26:53 GMT, Matthias Baesken wrote: > We can reduce the size of the jpackage.jmod by using SIZE optimization for the native components on Linux. > See > > > SIZE opt. > linuxx86_64 gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1292 images/jdk/jmods/jdk.jpackage.jmod > > linuxppc64le gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1416 images/jdk/jmods/jdk.jpackage.jmod > > > NORMAL opt. > linuxx86_64 gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1336 images/jdk/jmods/jdk.jpackage.jmod > > linuxppc64le gcc13 devkit > du -sk images/jdk/jmods/jdk.jpackage.jmod > 1460 images/jdk/jmods/jdk.jpackage.jmod This pull request has now been integrated. Changeset: 8620e67c Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/8620e67c87cf561c858c2528b3b00b016eec3a51 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8377231: Build jpackage with SIZE optimization Reviewed-by: erikj, asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/29585 From kcr at openjdk.org Fri Feb 6 13:26:10 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Feb 2026 13:26:10 GMT Subject: RFR: 8377231: Build jpackage with SIZE optimization In-Reply-To: References: <2HqS9tqNsXc6A8HpvtdI-C8iek8fh3g9eYl7glKT9l4=.f8d58f7d-f403-4f4c-9143-a45d73654631@github.com> Message-ID: On Fri, 6 Feb 2026 12:50:26 GMT, Alexey Semenyuk wrote: > @kevinrushforth, do we need another reviewer for this PR? I see that Erik and you both reviewed it, so no problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29585#issuecomment-3860427063 From lkorinth at openjdk.org Mon Feb 9 21:32:32 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 9 Feb 2026 21:32:32 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v3] In-Reply-To: References: Message-ID: > Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. > > My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. > > With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. > > This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. > > The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` > `module_file2.cpp_CXXFLAGS+=-Wconversion` > > this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > > (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: Using FindFiles in order to cache earlier file searches ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29523/files - new: https://git.openjdk.org/jdk/pull/29523/files/7964670b..a2f2d76e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29523.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29523/head:pull/29523 PR: https://git.openjdk.org/jdk/pull/29523 From kbarrett at openjdk.org Mon Feb 9 21:32:48 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 9 Feb 2026 21:32:48 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v3] In-Reply-To: References:

Message-ID: On Mon, 9 Feb 2026 19:37:02 GMT, Leo Korinth wrote: >> Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. >> >> My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. >> >> With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. >> >> This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. >> >> The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` >> `module_file2.cpp_CXXFLAGS+=-Wconversion` >> >> this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> >> (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > Using FindFiles in order to cache earlier file searches make/autoconf/flags-cflags.m4 line 238: > 236: DISABLED_WARNINGS="$DISABLED_WARNINGS psabi" > 237: fi > 238: CFLAGS_CONVERSION_WARNINGS="-Wconversion -Wno-float-conversion" Maybe this should be called `CFLAGS_INTEGRAL_CONVERSION_WARNINGS`? As there are other kinds of conversion warnings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2784194625 From acobbs at openjdk.org Tue Feb 10 02:38:09 2026 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 10 Feb 2026 02:38:09 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v8] In-Reply-To: References: Message-ID: <_JCaqe5WEHkjbjttTdOWj_iqkoUJpkMw3KjoVsem_Jg=.3558dcd1-6c15-49e9-adc9-b67ccd282197@github.com> > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 141 commits: - Merge branch 'master' into JDK-8344159 to fix conflicts. - Merge branch 'master' into JDK-8344159 to fix conflicts. - Update copyrights to 2026. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Suppress new unnecessary suppresion warnings created by recent commits. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflict. - ... and 131 more: https://git.openjdk.org/jdk/compare/57eb9c79...4fa9e3f0 ------------- Changes: https://git.openjdk.org/jdk/pull/25167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=07 Stats: 1695 lines in 37 files changed: 1492 ins; 50 del; 153 mod Patch: https://git.openjdk.org/jdk/pull/25167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167 PR: https://git.openjdk.org/jdk/pull/25167 From kbarrett at openjdk.org Tue Feb 10 05:44:09 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 10 Feb 2026 05:44:09 GMT Subject: RFR: 8332189: Enable -Wzero-as-null-pointer-constant for gcc/clang [v2] In-Reply-To: References: Message-ID: > Please review this change which enables `-Wzero-as-null-pointer-constant` > warnings in HotSpot code when building with gcc or clang. > > There are three parts to this change. > > The first part augments the warning flags setup to support adding warning > options that are only applied to HotSpot, rather than the JDK as a whole. > There was previously some unused and possibly incomplete support for this when > using gcc. Note that the Windows/Visual Studio support hasn't been tested > much, and I think might not be working yet. I'm going to investigate that > further in followup work. > > The second part enables `-Wzero-as-null-pointer-constant` for HotSpot code. > This follows the guidance to avoid such in the HotSpot Style Guide. > > The third part removes a note in the HotSpot Style Guide about lingering uses > of literal 0 as a null pointer constant. Those have been removed, and this > change will block backsliding. > > Testing: mach5 tier1, GHA Sanity tests > > Integration of this change needs to wait for JDK-8376758. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: update copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29497/files - new: https://git.openjdk.org/jdk/pull/29497/files/90ead8b1..ba299872 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29497&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29497&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29497/head:pull/29497 PR: https://git.openjdk.org/jdk/pull/29497 From kbarrett at openjdk.org Tue Feb 10 05:44:10 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 10 Feb 2026 05:44:10 GMT Subject: RFR: 8332189: Enable -Wzero-as-null-pointer-constant for gcc/clang [v2] In-Reply-To: References:

Message-ID: On Tue, 3 Feb 2026 10:46:54 GMT, Afshin Zafari wrote: > Thanks for this, Kim! Copyright year is to be updated, IMHO. Oops! Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29497#issuecomment-3875451090 From azafari at openjdk.org Tue Feb 10 09:30:11 2026 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 10 Feb 2026 09:30:11 GMT Subject: RFR: 8332189: Enable -Wzero-as-null-pointer-constant for gcc/clang [v2] In-Reply-To: References:

Message-ID: On Tue, 10 Feb 2026 05:44:09 GMT, Kim Barrett wrote: >> Please review this change which enables `-Wzero-as-null-pointer-constant` >> warnings in HotSpot code when building with gcc or clang. >> >> There are three parts to this change. >> >> The first part augments the warning flags setup to support adding warning >> options that are only applied to HotSpot, rather than the JDK as a whole. >> There was previously some unused and possibly incomplete support for this when >> using gcc. Note that the Windows/Visual Studio support hasn't been tested >> much, and I think might not be working yet. I'm going to investigate that >> further in followup work. >> >> The second part enables `-Wzero-as-null-pointer-constant` for HotSpot code. >> This follows the guidance to avoid such in the HotSpot Style Guide. >> >> The third part removes a note in the HotSpot Style Guide about lingering uses >> of literal 0 as a null pointer constant. Those have been removed, and this >> change will block backsliding. >> >> Testing: mach5 tier1, GHA Sanity tests >> >> Integration of this change needs to wait for JDK-8376758. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > update copyright Thanks. LGTM. ------------- Marked as reviewed by azafari (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29497#pullrequestreview-3777769510 From lkorinth at openjdk.org Tue Feb 10 10:03:08 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 10 Feb 2026 10:03:08 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v4] In-Reply-To: References: Message-ID: > Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. > > My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. > > With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. > > This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. > > The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` > `module_file2.cpp_CXXFLAGS+=-Wconversion` > > this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > > (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: add comment regarding usage of function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29523/files - new: https://git.openjdk.org/jdk/pull/29523/files/a2f2d76e..f17700f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=02-03 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29523.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29523/head:pull/29523 PR: https://git.openjdk.org/jdk/pull/29523 From cstein at openjdk.org Wed Feb 11 09:45:31 2026 From: cstein at openjdk.org (Christian Stein) Date: Wed, 11 Feb 2026 09:45:31 GMT Subject: Integrated: 8376355: Update to use jtreg 8.2.1 In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 15:26:20 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 8.2.1. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. This pull request has now been integrated. Changeset: 1e99cc48 Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/1e99cc4880f695c12705d849d41609f176f897bd Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod 8376355: Update to use jtreg 8.2.1 Reviewed-by: iris, erikj, shade ------------- PR: https://git.openjdk.org/jdk/pull/29452 From kbarrett at openjdk.org Wed Feb 11 09:46:07 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 11 Feb 2026 09:46:07 GMT Subject: RFR: 8332189: Enable -Wzero-as-null-pointer-constant for gcc/clang [v2] In-Reply-To: References:

Message-ID: On Tue, 10 Feb 2026 09:26:49 GMT, Afshin Zafari wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright > > Thanks. > LGTM. Thanks for reviews @afshin-zafari , @erikj79 , and @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/29497#issuecomment-3881551279 From kbarrett at openjdk.org Wed Feb 11 09:46:19 2026 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 11 Feb 2026 09:46:19 GMT Subject: Integrated: 8332189: Enable -Wzero-as-null-pointer-constant for gcc/clang In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 00:16:54 GMT, Kim Barrett wrote: > Please review this change which enables `-Wzero-as-null-pointer-constant` > warnings in HotSpot code when building with gcc or clang. > > There are three parts to this change. > > The first part augments the warning flags setup to support adding warning > options that are only applied to HotSpot, rather than the JDK as a whole. > There was previously some unused and possibly incomplete support for this when > using gcc. Note that the Windows/Visual Studio support hasn't been tested > much, and I think might not be working yet. I'm going to investigate that > further in followup work. > > The second part enables `-Wzero-as-null-pointer-constant` for HotSpot code. > This follows the guidance to avoid such in the HotSpot Style Guide. > > The third part removes a note in the HotSpot Style Guide about lingering uses > of literal 0 as a null pointer constant. Those have been removed, and this > change will block backsliding. > > Testing: mach5 tier1, GHA Sanity tests > > Integration of this change needs to wait for JDK-8376758. This pull request has now been integrated. Changeset: 4e3033f2 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/4e3033f2122d773c173b0bb50120099589adcf3c Stats: 41 lines in 3 files changed: 14 ins; 13 del; 14 mod 8332189: Enable -Wzero-as-null-pointer-constant for gcc/clang Reviewed-by: azafari, dholmes, erikj ------------- PR: https://git.openjdk.org/jdk/pull/29497 From mbaesken at openjdk.org Wed Feb 11 15:17:30 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Feb 2026 15:17:30 GMT Subject: RFR: 8377666: Fedora 41 based devkit build should load more packages from archive location Message-ID: <1xFjne_kY0eLBaOMI_O1QrozG2D2dEp_d_MEan8zuf0=.0e543378-fdb7-4c11-a16d-78b263c824a1@github.com> Seems Fedora 41 went into the archive too, see the README https://dl.fedoraproject.org/pub/fedora/linux/releases/41/README " ... The contents of this directory have been moved to our archives available at: http://archives.fedoraproject.org/pub/archive/fedora/ " So we should adjust the devkit Makefile. Currently we get this make tars BASE_OS=Fedora ... Connecting to dl.fedoraproject.org (dl.fedoraproject.org)|38.145.32.24|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2026-02-11 14:58:25 ERROR 404: Not Found. ------------- Commit messages: - JDK-8377666 Changes: https://git.openjdk.org/jdk/pull/29674/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29674&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377666 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29674/head:pull/29674 PR: https://git.openjdk.org/jdk/pull/29674 From clanger at openjdk.org Wed Feb 11 15:39:04 2026 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 11 Feb 2026 15:39:04 GMT Subject: RFR: 8377666: Fedora 41 based devkit build should load more packages from archive location In-Reply-To: <1xFjne_kY0eLBaOMI_O1QrozG2D2dEp_d_MEan8zuf0=.0e543378-fdb7-4c11-a16d-78b263c824a1@github.com> References: <1xFjne_kY0eLBaOMI_O1QrozG2D2dEp_d_MEan8zuf0=.0e543378-fdb7-4c11-a16d-78b263c824a1@github.com> Message-ID: On Wed, 11 Feb 2026 14:56:48 GMT, Matthias Baesken wrote: > Seems Fedora 41 went into the archive too, see the README https://dl.fedoraproject.org/pub/fedora/linux/releases/41/README > " ... The contents of this directory have been moved to our archives available at: http://archives.fedoraproject.org/pub/archive/fedora/ " > > So we should adjust the devkit Makefile. > Currently we get this > > > make tars BASE_OS=Fedora > ... > Connecting to dl.fedoraproject.org (dl.fedoraproject.org)|38.145.32.24|:443... connected. > HTTP request sent, awaiting response... 404 Not Found > 2026-02-11 14:58:25 ERROR 404: Not Found. Looks correct and you verified it. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29674#pullrequestreview-3785579570 From erikj at openjdk.org Wed Feb 11 17:39:20 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 11 Feb 2026 17:39:20 GMT Subject: RFR: 8377666: Fedora 41 based devkit build should load more packages from archive location In-Reply-To: <1xFjne_kY0eLBaOMI_O1QrozG2D2dEp_d_MEan8zuf0=.0e543378-fdb7-4c11-a16d-78b263c824a1@github.com> References: <1xFjne_kY0eLBaOMI_O1QrozG2D2dEp_d_MEan8zuf0=.0e543378-fdb7-4c11-a16d-78b263c824a1@github.com> Message-ID: On Wed, 11 Feb 2026 14:56:48 GMT, Matthias Baesken wrote: > Seems Fedora 41 went into the archive too, see the README https://dl.fedoraproject.org/pub/fedora/linux/releases/41/README > " ... The contents of this directory have been moved to our archives available at: http://archives.fedoraproject.org/pub/archive/fedora/ " > > So we should adjust the devkit Makefile. > Currently we get this > > > make tars BASE_OS=Fedora > ... > Connecting to dl.fedoraproject.org (dl.fedoraproject.org)|38.145.32.24|:443... connected. > HTTP request sent, awaiting response... 404 Not Found > 2026-02-11 14:58:25 ERROR 404: Not Found. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29674#pullrequestreview-3786265866 From lkorinth at openjdk.org Wed Feb 11 18:56:58 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 11 Feb 2026 18:56:58 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v3] In-Reply-To: References:

Message-ID: On Mon, 9 Feb 2026 19:36:36 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> Using FindFiles in order to cache earlier file searches > > make/autoconf/flags-cflags.m4 line 238: > >> 236: DISABLED_WARNINGS="$DISABLED_WARNINGS psabi" >> 237: fi >> 238: CFLAGS_CONVERSION_WARNINGS="-Wconversion -Wno-float-conversion" > > Maybe this should be called `CFLAGS_INTEGRAL_CONVERSION_WARNINGS`? As > there are other kinds of conversion warnings. >From start it was including all floating point conversion warnings (before your changes), and I still get gcc warnigs involving floating point values: `error: conversion from 'jlong' {aka 'long int'} to 'double' may change value [-Werror=conversion]` with the command line ending in `-Wconversion -Wno-float-conversion` I think the reason is that only disables real-to-real and real-to-integral, but does not disables integral-to-real (that can also be lossy). Let us keep the name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2794921009 From erikj at openjdk.org Wed Feb 11 19:25:04 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 11 Feb 2026 19:25:04 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v4] In-Reply-To: References:

Message-ID: On Tue, 10 Feb 2026 10:03:08 GMT, Leo Korinth wrote: >> Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. >> >> My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. >> >> With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. >> >> This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. >> >> The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` >> `module_file2.cpp_CXXFLAGS+=-Wconversion` >> >> this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` >> >> (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > add comment regarding usage of function make/hotspot/lib/CompileJvm.gmk line 192: > 190: abstract_vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ > 191: arguments.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ > 192: $(call extendingFlags,$(TOPDIR)/src/hotspot/share/gc/g1,g1ConcurrentMark.cpp,_CXXFLAGS,$(CFLAGS_CONVERSION_WARNINGS)), \ Looking at this from a style perspective, we generally name macros with initial letter capitalized. We also tend to use imperative mood, e.g. ExtendFlags rather than extendingFlags. Looking at this call, can you make it work with whitespace after comma, i.e. add calls to `strip` for every parameter in the top level macro. I know it makes the macro definition harder to read, but it's required to be able to line break this call, which it very much needs to be possible to do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2795039465 From mbaesken at openjdk.org Thu Feb 12 12:57:19 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 12 Feb 2026 12:57:19 GMT Subject: RFR: 8377666: Fedora 41 based devkit build should load more packages from archive location In-Reply-To: <1xFjne_kY0eLBaOMI_O1QrozG2D2dEp_d_MEan8zuf0=.0e543378-fdb7-4c11-a16d-78b263c824a1@github.com> References: <1xFjne_kY0eLBaOMI_O1QrozG2D2dEp_d_MEan8zuf0=.0e543378-fdb7-4c11-a16d-78b263c824a1@github.com> Message-ID: On Wed, 11 Feb 2026 14:56:48 GMT, Matthias Baesken wrote: > Seems Fedora 41 went into the archive too, see the README https://dl.fedoraproject.org/pub/fedora/linux/releases/41/README > " ... The contents of this directory have been moved to our archives available at: http://archives.fedoraproject.org/pub/archive/fedora/ " > > So we should adjust the devkit Makefile. > Currently we get this > > > make tars BASE_OS=Fedora > ... > Connecting to dl.fedoraproject.org (dl.fedoraproject.org)|38.145.32.24|:443... connected. > HTTP request sent, awaiting response... 404 Not Found > 2026-02-11 14:58:25 ERROR 404: Not Found. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29674#issuecomment-3890798886 From mbaesken at openjdk.org Thu Feb 12 13:02:21 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 12 Feb 2026 13:02:21 GMT Subject: Integrated: 8377666: Fedora 41 based devkit build should load more packages from archive location In-Reply-To: <1xFjne_kY0eLBaOMI_O1QrozG2D2dEp_d_MEan8zuf0=.0e543378-fdb7-4c11-a16d-78b263c824a1@github.com> References: <1xFjne_kY0eLBaOMI_O1QrozG2D2dEp_d_MEan8zuf0=.0e543378-fdb7-4c11-a16d-78b263c824a1@github.com> Message-ID: On Wed, 11 Feb 2026 14:56:48 GMT, Matthias Baesken wrote: > Seems Fedora 41 went into the archive too, see the README https://dl.fedoraproject.org/pub/fedora/linux/releases/41/README > " ... The contents of this directory have been moved to our archives available at: http://archives.fedoraproject.org/pub/archive/fedora/ " > > So we should adjust the devkit Makefile. > Currently we get this > > > make tars BASE_OS=Fedora > ... > Connecting to dl.fedoraproject.org (dl.fedoraproject.org)|38.145.32.24|:443... connected. > HTTP request sent, awaiting response... 404 Not Found > 2026-02-11 14:58:25 ERROR 404: Not Found. This pull request has now been integrated. Changeset: 09db4bce Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/09db4bce5c66cbfc7a7e04f87873a078ef694cc5 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8377666: Fedora 41 based devkit build should load more packages from archive location Reviewed-by: clanger, erikj ------------- PR: https://git.openjdk.org/jdk/pull/29674 From lkorinth at openjdk.org Thu Feb 12 17:36:04 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 12 Feb 2026 17:36:04 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v5] In-Reply-To: References: Message-ID: > Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. > > My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. > > With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. > > This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. > > The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` > `module_file2.cpp_CXXFLAGS+=-Wconversion` > > this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > `module_file3.cpp_CXXFLAGS+=$(SPACE)-Wotherflag` > > (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: Start with capital, strip spaces, use imperative mood, remove redundant comma ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29523/files - new: https://git.openjdk.org/jdk/pull/29523/files/f17700f1..f013c468 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=03-04 Stats: 28 lines in 2 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/29523.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29523/head:pull/29523 PR: https://git.openjdk.org/jdk/pull/29523 From lkorinth at openjdk.org Thu Feb 12 17:36:07 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 12 Feb 2026 17:36:07 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v4] In-Reply-To: References:

Message-ID: On Wed, 11 Feb 2026 19:19:11 GMT, Erik Joelsson wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> add comment regarding usage of function > > make/hotspot/lib/CompileJvm.gmk line 192: > >> 190: abstract_vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >> 191: arguments.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >> 192: $(call extendingFlags,$(TOPDIR)/src/hotspot/share/gc/g1,g1ConcurrentMark.cpp,_CXXFLAGS,$(CFLAGS_CONVERSION_WARNINGS)), \ > > Looking at this from a style perspective, we generally name macros with initial letter capitalized. We also tend to use imperative mood, e.g. ExtendFlags rather than extendingFlags. > > Looking at this call, can you make it work with whitespace after comma, i.e. add calls to `strip` for every parameter in the top level macro. I know it makes the macro definition harder to read, but it's required to be able to line break this call, which it very much needs to be possible to do. I think I have addressed it all in the latest push. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2800172599 From erikj at openjdk.org Thu Feb 12 19:17:49 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 12 Feb 2026 19:17:49 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v5] In-Reply-To: References:

Message-ID: On Thu, 12 Feb 2026 17:36:04 GMT, Leo Korinth wrote: >> Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. >> >> My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. >> >> With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. >> >> This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. >> >> The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` >> `module_file2.cpp_CXXFLAGS+=-Wconversion` >> >> this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=-Wotherflag` >> `module_file3.cpp_CXXFLAGS+=-Wotherflag` >> >> (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > Start with capital, strip spaces, use imperative mood, remove redundant comma make/hotspot/lib/CompileJvm.gmk line 192: > 190: abstract_vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ > 191: arguments.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ > 192: $(call ExtendFlags,$(TOPDIR)/src/hotspot/share/gc/g1,g1ConcurrentMark.cpp,_CXXFLAGS,$(CFLAGS_CONVERSION_WARNINGS)), \ Please also adhere to the convention of using space after comma in the call. I think this line needs to be broken up too. As a general guide, the 80 char wide `#` lines should be seen as soft limits on line length. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2800632305 From jpai at openjdk.org Fri Feb 13 11:23:34 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 13 Feb 2026 11:23:34 GMT Subject: RFR: 8296183: jndiprovider.properties contains properties pointing to non-existing classes Message-ID: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com> Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183. This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this: Retrieves an enumeration of factory classes/object specified by a property. The property is gotten from the environment and the provider resource file associated with the given context and concatenated. ... The resulting property value is a list of class names. This method then loads each class using the current thread's context class loader and keeps them in a list. Any class that cannot be loaded is ignored. ... The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file. The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass. ------------- Commit messages: - remove reference to a non-existent class from @see of EntryChangeResponseControl - 8296183: jndiprovider.properties contains properties pointing to non-existing classes Changes: https://git.openjdk.org/jdk/pull/29712/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29712&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296183 Stats: 21 lines in 3 files changed: 0 ins; 19 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29712.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29712/head:pull/29712 PR: https://git.openjdk.org/jdk/pull/29712 From dfuchs at openjdk.org Fri Feb 13 12:05:20 2026 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 13 Feb 2026 12:05:20 GMT Subject: RFR: 8296183: jndiprovider.properties contains properties pointing to non-existing classes In-Reply-To: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com> References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com> Message-ID: On Fri, 13 Feb 2026 11:15:00 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183. > > This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this: > > > Retrieves an enumeration of factory classes/object specified by a property. > > The property is gotten from the environment and the provider resource file associated with the given context and concatenated. > ... The resulting property value is a list of class names. > This method then loads each class using the current thread's context class loader and keeps them in a list. > Any class that cannot be loaded is ignored. > ... > > > The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file. > > The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass. Generally looks good to me. Good to avoid those unneeded CNFE. If backported, some more checks might be required on JDK 8 - as CORBA is still supported there. src/java.naming/share/classes/com/sun/jndi/ldap/EntryChangeResponseControl.java line 54: > 52: * > 53: * @see PersistentSearchControl > 54: */ Not that it matters much, but I see that `DefaultResponseControlFactory` and `PersistentSearchControl` both have an `@see EntryChangeResponseControl` so I'd suggest to replace: - * @see com.sun.jndi.ldap.ctl.ResponseControlFactory ResponseControlFactory + * @see DefaultResponseControlFactory ------------- PR Review: https://git.openjdk.org/jdk/pull/29712#pullrequestreview-3796864479 PR Review Comment: https://git.openjdk.org/jdk/pull/29712#discussion_r2803848914 From jpai at openjdk.org Fri Feb 13 12:14:28 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 13 Feb 2026 12:14:28 GMT Subject: RFR: 8296183: jndiprovider.properties contains properties pointing to non-existing classes [v2] In-Reply-To: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com> References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com> Message-ID: > Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183. > > This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this: > > > Retrieves an enumeration of factory classes/object specified by a property. > > The property is gotten from the environment and the provider resource file associated with the given context and concatenated. > ... The resulting property value is a list of class names. > This method then loads each class using the current thread's context class loader and keeps them in a list. > Any class that cannot be loaded is ignored. > ... > > > The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file. > > The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: add reference to DefaultResponseControlFactory in javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29712/files - new: https://git.openjdk.org/jdk/pull/29712/files/1864e84a..b68385a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29712&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29712&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29712.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29712/head:pull/29712 PR: https://git.openjdk.org/jdk/pull/29712 From dfuchs at openjdk.org Fri Feb 13 12:14:28 2026 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 13 Feb 2026 12:14:28 GMT Subject: RFR: 8296183: jndiprovider.properties contains properties pointing to non-existing classes [v2] In-Reply-To: References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com> Message-ID: On Fri, 13 Feb 2026 12:11:30 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183. >> >> This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this: >> >> >> Retrieves an enumeration of factory classes/object specified by a property. >> >> The property is gotten from the environment and the provider resource file associated with the given context and concatenated. >> ... The resulting property value is a list of class names. >> This method then loads each class using the current thread's context class loader and keeps them in a list. >> Any class that cannot be loaded is ignored. >> ... >> >> >> The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file. >> >> The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > add reference to DefaultResponseControlFactory in javadoc Would be good to get @AlekseiEfimov approval before integrating. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29712#pullrequestreview-3796912823 From jpai at openjdk.org Fri Feb 13 12:14:30 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 13 Feb 2026 12:14:30 GMT Subject: RFR: 8296183: jndiprovider.properties contains properties pointing to non-existing classes [v2] In-Reply-To: References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com> Message-ID: On Fri, 13 Feb 2026 11:57:31 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> add reference to DefaultResponseControlFactory in javadoc > > src/java.naming/share/classes/com/sun/jndi/ldap/EntryChangeResponseControl.java line 54: > >> 52: * >> 53: * @see PersistentSearchControl >> 54: */ > > Not that it matters much, but I see that `DefaultResponseControlFactory` and `PersistentSearchControl` both have an `@see EntryChangeResponseControl` so I'd suggest to replace: > > > - * @see com.sun.jndi.ldap.ctl.ResponseControlFactory ResponseControlFactory > + * @see DefaultResponseControlFactory That's a good point, I've updated the PR accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29712#discussion_r2803888024 From Suchismith.Roy at ibm.com Fri Feb 13 12:52:50 2026 From: Suchismith.Roy at ibm.com (Suchismith Roy) Date: Fri, 13 Feb 2026 12:52:50 +0000 Subject: JDK-8216554 Message-ID: Hi All I am currently working on JDK-8216554 , which is related to optimise loading of constants in c2 compilation by determining the size of TOC in post_alloc stage. This is for PowerPC Currently there is a default code that emits combination of addis+ld instruction even in possible cases where only ld instruction can be emitted. There is an alternate code based on small size of TOC that emits only ld, but we are not taking it. I tried to do a gdb debug, i am unable to get the constant table size at post_alloc stage. It is only after the emit stage we get the size of TOC. Does that mean we cannot ever get accurate size in post_alloc stage ? I also tried a test case and forced the c2 compiler emit ld only. Interestingly, the global size of TOC was large and calculated much later, and macroassembler puts in addis+addi . So the case of large offset, even if miscalculated in post_alloc stage , is handled in some way. Does that mean we can just keep the conservative path of emitting Addis+addi ? Or maybe we can even remove the helper function in post_alloc stage. Open to your suggestions. Will provide a few debug logs too as per your request. Thanks Suchismith Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkorinth at openjdk.org Fri Feb 13 13:13:31 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 13 Feb 2026 13:13:31 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v5] In-Reply-To: References:

Message-ID: On Thu, 12 Feb 2026 19:14:52 GMT, Erik Joelsson wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> Start with capital, strip spaces, use imperative mood, remove redundant comma > > make/hotspot/lib/CompileJvm.gmk line 192: > >> 190: abstract_vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >> 191: arguments.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ >> 192: $(call ExtendFlags,$(TOPDIR)/src/hotspot/share/gc/g1,g1ConcurrentMark.cpp,_CXXFLAGS,$(CFLAGS_CONVERSION_WARNINGS)), \ > > Please also adhere to the convention of using space after comma in the call. I think this line needs to be broken up too. As a general guide, the 80 char wide `#` lines should be seen as soft limits on line length. Okay, I will probably remove the line before integrating as it currently breaks the build with new warnings. But if I get the source fixed before this change is integrated, I will add space after comma and try to line break at ~80. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29523#discussion_r2804149941 From aefimov at openjdk.org Fri Feb 13 15:32:25 2026 From: aefimov at openjdk.org (Aleksei Efimov) Date: Fri, 13 Feb 2026 15:32:25 GMT Subject: RFR: 8296183: jndiprovider.properties contains properties pointing to non-existing classes [v2] In-Reply-To: References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com> Message-ID: <5VuKXi3KCmZl39MqG7KzHv4pjDOGyR0DAA5p5l5z7n8=.f332a60d-01b8-4056-bd74-125d86571f42@github.com> On Fri, 13 Feb 2026 12:14:28 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183. >> >> This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this: >> >> >> Retrieves an enumeration of factory classes/object specified by a property. >> >> The property is gotten from the environment and the provider resource file associated with the given context and concatenated. >> ... The resulting property value is a list of class names. >> This method then loads each class using the current thread's context class loader and keeps them in a list. >> Any class that cannot be loaded is ignored. >> ... >> >> >> The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file. >> >> The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > add reference to DefaultResponseControlFactory in javadoc Looks good to me ------------- Marked as reviewed by aefimov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29712#pullrequestreview-3797906237 From asarkar at openjdk.org Fri Feb 13 21:15:40 2026 From: asarkar at openjdk.org (Anirvan Sarkar) Date: Fri, 13 Feb 2026 21:15:40 GMT Subject: RFR: 8296183: jndiprovider.properties contains properties pointing to non-existing classes [v2] In-Reply-To: References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com> Message-ID: <5KrG_KONacK8ssoB822zQJZ2mP772ddAOPrEnAB5dBw=.954d7d11-ba31-405a-a2b1-2b1de23c0b15@github.com> On Fri, 13 Feb 2026 12:14:28 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183. >> >> This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this: >> >> >> Retrieves an enumeration of factory classes/object specified by a property. >> >> The property is gotten from the environment and the provider resource file associated with the given context and concatenated. >> ... The resulting property value is a list of class names. >> This method then loads each class using the current thread's context class loader and keeps them in a list. >> Any class that cannot be loaded is ignored. >> ... >> >> >> The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file. >> >> The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > add reference to DefaultResponseControlFactory in javadoc >Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8) It seems these classes were never part of the JDK. These classes were part of the (legacy?) JNDI/LDAP booster pack `ldapbp.jar` available as a separate download. The download file is currently `ldap-1_2_4.zip` in the Oracle Java Archive for Java Platform Technologies [1]. Software vendors required `ldapbp.jar` to be added to the `CLASSPATH`. The very old JNDI tutorial also references `ldapbp.jar` [2]. Booster pack has the following packages: | Package | Contents | |----------------------------|---------------------------------------------------| | com.sun.jndi.ldap.obj | RMI, CORBA support for LDAP Service Provider for JNDI | | com.sun.security.sasl.misc | CRAM-MD5, Anonymous, and Plain SASL Drivers | | com.sun.jndi.ldap.ctl | Controls for LDAP Service Provider for JNDI | The packages `com.sun.security.sasl.misc` and `com.sun.jndi.ldap.ctl` became obsolete when its support was included in the JDK 5. I suspect the classes of package `com.sun.jndi.ldap.obj` were not included in JDK, as RFC 2713 & RFC 2714 were not standardized unlike other RFCs related to LDAP. The booster pack is also available on Maven repository [3]. Do you think any of its dependencies could be impacted by removal of `jndiprovider.properties` file? Should this removal be mentioned in the release notes? If you want to look at the booster pack?s source code, it?s included in GlassFish 5 [4]. [1] : https://www.oracle.com/java/technologies/java-archive-downloads-java-plat-downloads.html#7110-jndi-1.2.1-oth-JPR [2] : https://docs.oracle.com/javase/jndi/tutorial/objects/storing/index.html [3] : https://mvnrepository.com/artifact/com.sun/ldapbp [4] : https://github.com/javaee/glassfish/tree/master/appserver/ldapbp/src/main/java/com/sun/jndi/ldap ------------- PR Comment: https://git.openjdk.org/jdk/pull/29712#issuecomment-3899500761 From jpai at openjdk.org Mon Feb 16 10:37:10 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 16 Feb 2026 10:37:10 GMT Subject: RFR: 8296183: jndiprovider.properties contains properties pointing to non-existing classes [v2] In-Reply-To: <5KrG_KONacK8ssoB822zQJZ2mP772ddAOPrEnAB5dBw=.954d7d11-ba31-405a-a2b1-2b1de23c0b15@github.com> References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com> <5KrG_KONacK8ssoB822zQJZ2mP772ddAOPrEnAB5dBw=.954d7d11-ba31-405a-a2b1-2b1de23c0b15@github.com> Message-ID: On Fri, 13 Feb 2026 21:13:00 GMT, Anirvan Sarkar wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> add reference to DefaultResponseControlFactory in javadoc > >>Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8) > > It seems these classes were never part of the JDK. > These classes were part of the (legacy?) JNDI/LDAP booster pack `ldapbp.jar` available as a separate download. > The download file is currently `ldap-1_2_4.zip` in the Oracle Java Archive for Java Platform Technologies [1]. > > Software vendors required `ldapbp.jar` to be added to the `CLASSPATH`. > The very old JNDI tutorial also references `ldapbp.jar` [2]. > > Booster pack has the following packages: > > | Package | Contents | > |----------------------------|---------------------------------------------------| > | com.sun.jndi.ldap.obj | RMI, CORBA support for LDAP Service Provider for JNDI | > | com.sun.security.sasl.misc | CRAM-MD5, Anonymous, and Plain SASL Drivers | > | com.sun.jndi.ldap.ctl | Controls for LDAP Service Provider for JNDI | > > The packages `com.sun.security.sasl.misc` and `com.sun.jndi.ldap.ctl` became obsolete when its support was included in the JDK 5. > > I suspect the classes of package `com.sun.jndi.ldap.obj` were not included in JDK, as RFC 2713 & RFC 2714 were not standardized unlike other RFCs related to LDAP. > > The booster pack is also available on Maven repository [3]. > Do you think any of its dependencies could be impacted by removal of `jndiprovider.properties` file? > Should this removal be mentioned in the release notes? > > If you want to look at the booster pack?s source code, it?s included in GlassFish 5 [4]. > > [1] : https://www.oracle.com/java/technologies/java-archive-downloads-java-plat-downloads.html#7110-jndi-1.2.1-oth-JPR > [2] : https://docs.oracle.com/javase/jndi/tutorial/objects/storing/index.html > [3] : https://mvnrepository.com/artifact/com.sun/ldapbp > [4] : https://github.com/javaee/glassfish/tree/master/appserver/ldapbp/src/main/java/com/sun/jndi/ldap Thank you for those details @AnirvanSarkar. This helped understand where these values came from. > Do you think any of its dependencies could be impacted by removal of jndiprovider.properties file? Should this removal be mentioned in the release notes? Having read and reviewed those details, I think this will need a release note and also a CSR. The `jndiprovider.properties` that is shipped by the `java.naming` module references classes that don't belong to the JDK. Yet, some of the (seemingly outdated) documentation (including the tutorial you pointed to) instruct applications to include a LDAP provider specific JAR file in the classpath of the application and expect the LDAP provider to load the classes configured in the `java.naming` module's `jndiprovider.properties`. Before the changes in this PR, code like the following public class Test { public static void main(final String[] args) throws Exception { final Hashtable envProps = new Hashtable<>(); envProps.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); envProps.put("java.naming.ldap.version", "3"); envProps.put(Context.PROVIDER_URL, "ldap://127.0.0.1:12345"); // LDAP server final Context ctx = NamingManager.getInitialContext(envProps); System.out.println("Got context " + ctx); final Object obj = NamingManager.getObjectInstance(new java.rmi.MarshalledObject(new String("foo")), new LdapName("CN=foo"), ctx, envProps); System.out.println("Got object instance " + obj + " type " + obj.getClass()); } } when launched with the LDAP booster pack JAR in the application classpath would return: java -cp ldapbp-1.0.jar Test.java Got context com.sun.jndi.ldap.LdapCtx at 1f3f4916 Got object instance foo type class java.lang.String (notice the return type of `obj` is `java.lang.String`) What this implies is that the LDAP service provider in the JDK picked up the `jndiprovider.properties` from the `java.naming` module and noticed the: java.naming.factory.object=com.sun.jndi.ldap.obj.AttrsToCorba:com.sun.jndi.ldap.obj.MarshalledToObject property value and loaded the `com.sun.jndi.ldap.obj.MarshalledToObject` from the JAR file in the application classpath and invoked it to return the `java.lang.String` output. With the proposed change, the LDAP provider will no longer by default set the `java.naming.factory.object` (and the other two) properties. Thus the LDAP provider will no longer attempt to load `com.sun.jndi.ldap.obj.MarshalledToObject` and as a result, the same application code will now see the following result: java -cp ldapbp-1.0.jar Test.java Got context com.sun.jndi.ldap.LdapCtx at 14a2f921 Got object instance java.rmi.MarshalledObject at a546def5 type class java.rmi.MarshalledObject (notice how the return type is now `java.rmi.MarshalledObject`) So yes, this change will have an impact on applications. The javadoc of `javax.naming.Context` specifies how/where the environment properties are picked up https://docs.oracle.com/en/java/javase/25/docs/api/java.naming/javax/naming/Context.html#resource-files-heading. With the change being proposed in this PR, the applications will now have to explicitly pass the values for: java.naming.factory.control java.naming.factory.object java.naming.factory.state if they want those values to be used by the LDAP service provider. So the application would have to do something like: ... envProps.put("java.naming.factory.object", "com.sun.jndi.ldap.obj.AttrsToCorba:com.sun.jndi.ldap.obj.MarshalledToObject"); ... to instruct LDAP provider to use those classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29712#issuecomment-3907698917 From duke at openjdk.org Tue Feb 17 22:43:47 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Tue, 17 Feb 2026 22:43:47 GMT Subject: RFR: 8374045: Add support to run benchmarking with fragmented CodeCache [v2] In-Reply-To: <28XEl5CuISOqvXzqKriK_Syebek7Txgot5gD_yVD8vo=.07dabc2f-2f2b-4faa-b85f-03ad6e222a1c@github.com> References: <28XEl5CuISOqvXzqKriK_Syebek7Txgot5gD_yVD8vo=.07dabc2f-2f2b-4faa-b85f-03ad6e222a1c@github.com> Message-ID: > [JDK-8374045](https://bugs.openjdk.org/browse/JDK-8374045) > > This PR adds a new utility tool CodeCacheFragmenter to help with testing HotSpot code cache fragmentation scenarios. The tool is a Java agent that uses the WhiteBox API to create and randomly free dummy code blobs in the NonProfiled code heap to achieve a specified fill percentage. It includes configurable parameters for blob sizes, target fill percentage (0-100%), and random seeding to enable reproducible fragmentation patterns. The utility is built via a standard Makefile and produces `codecachefragmenter.jar` which can be used as a Java agent with `-javaagent` flag. This tool is intended for performance testing and experimentation with code cache behavior under various fragmentation conditions. > > This is useful to show the performance benefits of [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205) > > With the same amount of free code cache memory, adding fragmentation increases execution time of Renaissance Dotty by ~5x. See https://github.com/openjdk/jdk/pull/28934#issuecomment-3820151693 for more details. Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: Update rng ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28934/files - new: https://git.openjdk.org/jdk/pull/28934/files/c2108d55..f40ad8c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28934&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28934&range=00-01 Stats: 18 lines in 2 files changed: 2 ins; 5 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/28934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28934/head:pull/28934 PR: https://git.openjdk.org/jdk/pull/28934 From duke at openjdk.org Tue Feb 17 23:01:12 2026 From: duke at openjdk.org (Chad Rakoczy) Date: Tue, 17 Feb 2026 23:01:12 GMT Subject: RFR: 8374045: Add support to run benchmarking with fragmented CodeCache [v2] In-Reply-To: References: <28XEl5CuISOqvXzqKriK_Syebek7Txgot5gD_yVD8vo=.07dabc2f-2f2b-4faa-b85f-03ad6e222a1c@github.com> Message-ID: On Tue, 17 Feb 2026 22:43:47 GMT, Chad Rakoczy wrote: >> [JDK-8374045](https://bugs.openjdk.org/browse/JDK-8374045) >> >> This PR adds a new utility tool CodeCacheFragmenter to help with testing HotSpot code cache fragmentation scenarios. The tool is a Java agent that uses the WhiteBox API to create and randomly free dummy code blobs in the NonProfiled code heap to achieve a specified fill percentage. It includes configurable parameters for blob sizes, target fill percentage (0-100%), and random seeding to enable reproducible fragmentation patterns. The utility is built via a standard Makefile and produces `codecachefragmenter.jar` which can be used as a Java agent with `-javaagent` flag. This tool is intended for performance testing and experimentation with code cache behavior under various fragmentation conditions. The distribution of blob sizes aims to represent real world nmethod sizes which are based on sizes from running Renaissance benchmarks. >> >> This is useful to show the performance benefits of [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205) >> >> Distribution of nmethod size from Renaissance benchmarks: >> renaissance_dis

>> >> Distribution of dummy blob size from CodeCacheFragmenter: >> frag_new_dis

> > Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: > > Update rng Update random number generation for blob size to be more representative of real world workloads. Renaissance benchmarks: renaissance_dis

Old:

New:

------------- PR Comment: https://git.openjdk.org/jdk/pull/28934#issuecomment-3917507712 From lkorinth at openjdk.org Wed Feb 18 09:15:01 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 18 Feb 2026 09:15:01 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v6] In-Reply-To: References: Message-ID: > Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. > > My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. > > With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. > > This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. > > The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` > `module_file2.cpp_CXXFLAGS+=-Wconversion` > > this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=-Wotherflag` > `module_file3.cpp_CXXFLAGS+=-Wotherflag` > > (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: remove example usage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29523/files - new: https://git.openjdk.org/jdk/pull/29523/files/f013c468..2485c456 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29523.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29523/head:pull/29523 PR: https://git.openjdk.org/jdk/pull/29523 From lkorinth at openjdk.org Wed Feb 18 16:37:38 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 18 Feb 2026 16:37:38 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v6] In-Reply-To: References:

Message-ID: On Wed, 18 Feb 2026 09:15:01 GMT, Leo Korinth wrote: >> Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. >> >> My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. >> >> With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. >> >> This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. >> >> The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` >> `module_file2.cpp_CXXFLAGS+=-Wconversion` >> >> this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=-Wotherflag` >> `module_file3.cpp_CXXFLAGS+=-Wotherflag` >> >> (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > remove example usage I have removed the example usage of warning flags to remove the compiler errors before integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29523#issuecomment-3921847487 From lkorinth at openjdk.org Wed Feb 18 16:57:13 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 18 Feb 2026 16:57:13 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v7] In-Reply-To: References: Message-ID: > Allow conversion warnings in subsets of the code base. By allowing this, we can improve the code base in parts, and see that those parts do not regress in the future. > > My approach to implement this is by adding support to our make system to recognise and handle "variable packs". A "variable pack" is a list of quoted variable "appendings". It will be picked up by `NamedParamsMacroTemplate` and there recognised by the lack of an assignment operator that is always used when sending variables to macros today. To support sending lists of "variable appendings", the appendings must quote assignment, spaces and quotes. This would be cleanest to implement by hex or base64 encode the string. However, this is extremely hard to do in make, and I prefer not calling the likes of `od` or `base64` to make the code portable and fast. > > With this infrastructure I implement a simple recursive utility to find all files matching a pattern in a folder; I then transform that list to variable assignments that will add compiler warnings for those files. > > This approach is extremely flexible. I can for example combine many calls to the `overrideFlags` macro with different source directories and different patterns. > > The macro will expand to something like (depending on compiler): `module_file1.cpp_CXXFLAGS+=-Wconversion` > `module_file2.cpp_CXXFLAGS+=-Wconversion` > > this can flexibly be combined with other flags to overlap: `module_file2.cpp_CXXFLAGS+=-Wotherflag` > `module_file3.cpp_CXXFLAGS+=-Wotherflag` > > (note the overlapping sets of flags `file1 -Wconversion`, `file2 -Wconversion -Wotherflag`, `file3 -Wotherflag`) Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29523/files - new: https://git.openjdk.org/jdk/pull/29523/files/2485c456..16a3af2f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29523&range=05-06 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29523.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29523/head:pull/29523 PR: https://git.openjdk.org/jdk/pull/29523 From lkorinth at openjdk.org Wed Feb 18 16:57:15 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 18 Feb 2026 16:57:15 GMT Subject: RFR: 8376892: Allow conversion warnings in subsets of the code base [v6] In-Reply-To: References:

Message-ID: On Wed, 18 Feb 2026 16:34:42 GMT, Leo Korinth wrote: > I have removed the example usage of warning flags to remove the compiler errors before integrating. If you remove this example, then the new `CFLAGS_CONVERSION_WARNINGS` variable is unused. Even if you plan on using this in a followup change, I think it would be more appropriate to introduce the variable then. OTOH, the title of the bug is "Allow conversion warnings in subsets of the code base", which is rather specific, while the patch is introducing a rather generic mechanism for adding flags to arbitrary subsets of code. I see two ways forward: 1. Remove `CFLAGS_CONVERSION_WARNINGS` from this patch, update the title to reflect what the patch is actually doing (introducing a generic way of applying flags to subsets of files) and save the actual enabling of warnings for a separate patch. 2. Keep the title, but also define an initial set of files for which this warning can be enabled. I'm actually more comfortable with 2 as it doesn't introduce dead/unused code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29523#issuecomment-3922334717 From dtabata at openjdk.org Thu Feb 19 07:32:07 2026 From: dtabata at openjdk.org (Daishi Tabata) Date: Thu, 19 Feb 2026 07:32:07 GMT Subject: RFR: 8378218: MSYS2 reports cygwin triplet causing bash configure failure Message-ID: In the MSYS2 environment, the system is currently detected as a Cygwin environment. As a result, the following code is not executed under MSYS2, which in turn breaks the execution of?`cmd.exe /c`: if test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys2"; then # Must be done prior to calling any commands to avoid mangling of command line export MSYS2_ARG_CONV_EXCL="*" fi I considered three possible approaches to fix this issue: 1. Modify?`basic_windows.m4`?so that?`MSYS2_ARG_CONV_EXCL="*"`?is also set in non?MSYS2 environments (such as WSL and Cygwin). 2. Introduce the following logic early in the?`configure`?processing and set the environment variable?`$MSYSTEM_CHOST`?to the MSYS2 value: if test "x$MSYSTEM" != "x"; then MSYSTEM_CHOST="x86_64-pc-msys" fi 3. Add a note to?`build.md`?(the approach adopted in this PR). Approaches 1 and 2 are better in the sense that they do not require any additional steps at build time, but they also have issues. With approach 1, the build proceeds as if it were in a Cygwin environment even though it is actually an MSYS2 environment, which could lead to unexpected errors. With approach 2, the logic needs to run very early in the configure process (before PLATFORM_SETUP_OPENJDK_BUILD_AND_TARGET), and introducing platform?specific handling at such an early stage is not recommended. For these reasons, I chose approach 3. One concern I still have is whether this issue also occurs with the ARM version of MSYS2. Unfortunately, I do not have access to an ARM Windows environment and cannot verify this myself. For now, the addition to?`build.md`?is limited to?`x86?64`. If someone can confirm that the same problem occurs (or does not occur) on the latest ARM version of MSYS2, I will update the documentation accordingly. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/29810/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29810&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378218 Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29810.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29810/head:pull/29810 PR: https://git.openjdk.org/jdk/pull/29810 From jaikiran.pai at oracle.com Thu Feb 19 12:02:33 2026 From: jaikiran.pai at oracle.com (Jaikiran Pai) Date: Thu, 19 Feb 2026 17:32:33 +0530 Subject: JDK-8216554 In-Reply-To: References: Message-ID: <2b6c2107-a7b7-4d71-ae9a-402322e07025@oracle.com> Hello Suchismith, The question doesn't look related to building the JDK. I think hotspot-dev mailing list might be a better place to ask this question https://mail.openjdk.org/mailman/listinfo/hotspot-dev -Jaikiran On 13/02/26 6:22 pm, Suchismith Roy wrote: > Hi All > > I am currently working on?JDK-8216554 , which is related to optimise > loading of constants in c2 compilation by determining the size of TOC > in post_alloc stage. > This is for?PowerPC > Currently there is a default code that emits combination of addis+ld > instruction even in possible cases where only ld instruction can be > emitted. There is an alternate code based on small size of TOC that > emits only ld, but we are not taking it. > > I tried to do a gdb debug, i am unable to get the constant table size > at post_alloc stage. > It is only after the emit stage we get the size of TOC. > > Does that mean we cannot ever get accurate size in post_alloc stage ? > > I also tried a test case and forced the c2 compiler emit ld only. > > > Interestingly, the global size of TOC was large and calculated much > later, and macroassembler puts in addis+addi . > > So the case of large offset, even if miscalculated in post_alloc stage > , is handled in some way. > > Does that mean we can just keep the conservative path of emitting > Addis+addi ?? Or maybe we can even remove the helper function in > post_alloc stage. > > Open to your suggestions. Will provide a few debug logs too as per > your request. > > > Thanks > Suchismith Roy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikj at openjdk.org Thu Feb 19 14:23:53 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 19 Feb 2026 14:23:53 GMT Subject: RFR: 8378218: MSYS2 reports cygwin triplet causing bash configure failure In-Reply-To: References: