On Mon, 28 Apr 2025 20:08:00 GMT, Magnus Ihse Bursie wrote:
> Are we sure powershell is always installed on Windows?
I verified by running tests on all the Windows versions we use internally and
looked at the calculated concurrency in RunTest.gmk. If we didn't get a number
for memory I believe
On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata wrote:
>> After searching the entire JDK source code, I found that WMIC is only used
>> in four files. These WMIC calls can be replaced with PowerShell for WMI.
>>
>> The primary challenge in this replacement is to make it work the same as
>> bef
On Thu, 17 Apr 2025 00:24:50 GMT, Leonid Mesnik wrote:
> Added problemlists and and requires for execution tests with --enable-preview.
>
> The --enable-preview features might significantly change VM/JDK behavior and
> sometimes it is useful to run tests with preview features enabled. Eventuall
On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote:
> I have checked the entire code base for incorrect encodings, but luckily
> enough these were the only remaining problems I found.
>
> BOM (byte-order mark) is a method used for distinguishing big and little
> endian UTF-16 encoding
On Tue, 1 Apr 2025 13:22:47 GMT, Magnus Ihse Bursie wrote:
> The proper way to disable warnings is to use the DISABLED_WARNINGS arguments.
> In this particular case, there was already a pragma but due to incorrect
> restrictions it did not apply to clang.
Marked as reviewed by erikj (Reviewer)
On Wed, 19 Mar 2025 09:11:05 GMT, Alan Bateman wrote:
> For the folks targeting embedded/small environments then I think the right
> thing is to publish the packaged modules (JMOD files) for the target platform
> and then use `jlink` to create the run-image with the right VM + small set of
> m
On Tue, 18 Mar 2025 13:12:16 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.base/Copy.gmk line 128:
>>
>>> 126: $(foreach import_jvm, $(IMPORT_JVM_NAMES), \
>>> 127: $(eval $(import_jvm)_path := $(patsubst $(import_jvm):%,%,$(filter
>>> $(import_jvm):%, $(IMPORT_JVMS \
>>> 128:
On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote:
> We should allow pre-built JVMs to be included in a build, so they are just
> copied into place, and the jvm.cfg file properly updated.
If we want to support CDS archives for the imported JVMs, then we would need to
modify the loop i
On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote:
> We should allow pre-built JVMs to be included in a build, so they are just
> copied into place, and the jvm.cfg file properly updated.
make/modules/java.base/Copy.gmk line 128:
> 126: $(foreach import_jvm, $(IMPORT_JVM_NAMES), \
>
On Mon, 17 Mar 2025 13:11:14 GMT, Joachim Kern wrote:
>> Thanks Eric, this might help with the command, but my problem is the
>> dependency. The rules to generate the export files is not called, because in
>> the build output I cannot find any line 'Generating export list for static
>> libs'.
On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote:
> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are
> most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to
> HIGH.
Marked as rev
On Sat, 8 Mar 2025 13:39:44 GMT, snake66 wrote:
>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that
>> it's possible to parameterize this for platforms that use different flags
>> for enabling posix threads.
>>
>> This work is a continuation of the work done by Greg Lew
On Thu, 6 Mar 2025 10:39:27 GMT, snake66 wrote:
> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's
> possible to parameterize this for platforms that use different flags for
> enabling posix threads.
>
> This work is a continuation of the work done by Greg Lewis in
On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern wrote:
> After "JDK-8339480: Build static-jdk image with a statically linked launcher"
> AIX was not able to build the new target. Therefore with "JDK-8345590 AIX
> 'make all' fails after JDK-8339480" the new target was disabled again.
>
> Now wit
On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang wrote:
>> Simplify the layout access var handles to be direct in some common cases.
>> Also made `VarHandle::isAccessModeSupported` report if an access mode is
>> supported for a VH.
>>
>> Reduces the instructions to execute this code in a simple ma
On Wed, 19 Feb 2025 03:21:37 GMT, SendaoYan wrote:
>> Hi all,
>>
>> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()"
>> because "is" is null', because the file
>> 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing
>> the required xml input fil
On Fri, 14 Feb 2025 07:21:27 GMT, SendaoYan wrote:
> Hi all,
>
> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()"
> because "is" is null', because the file
> 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing
> the required xml input file defi
On Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote:
>> The idea.sh script which creates a configuration for IDEA does at some point
>> call a makefile, to extract information from the build system. However, this
>> is done in an ad-hoc manner that does not fit properly in the build syst
On Fri, 3 Jan 2025 12:46:27 GMT, Adam Sotona wrote:
> ASM-based benchmarks were useful to directly compare performance of ASM and
> Class-File API.
> However Class-File API performance history is now continuously tracked and
> direct comparison to ASM becomes obsolete.
>
> This patch removes A
On Tue, 24 Dec 2024 03:26:23 GMT, Qizheng Xing wrote:
>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with three additional
> commits since the last revision:
>
> - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.
On Mon, 23 Dec 2024 09:45:00 GMT, Qizheng Xing wrote:
> This patch fixes unmatched brackets in some source files.
I can really only review the doc files and the Makefile.
doc/hotspot-unit-tests.md line 175:
> 173: there is no need to have them in error messages. Asserts print only
> 174: compa
On Thu, 19 Dec 2024 16:27:30 GMT, Magnus Ihse Bursie wrote:
> We need to raise the abstraction of the SetupBuildLauncher API, to prepare
> for static launchers. We should specify the desired outcome, not what flags
> we should add. This can be seen as the last part of
> [JDK-8141444](https://b
On Fri, 20 Dec 2024 13:11:22 GMT, Magnus Ihse Bursie wrote:
>> When the static launcher was introduced in
>> [JDK-8339480](https://bugs.openjdk.org/browse/JDK-8339480), due to time and
>> resource constraints, it was only working properly on Linux and macOS, while
>> the Windows port compiled
On Tue, 17 Dec 2024 15:41:51 GMT, Magnus Ihse Bursie wrote:
> When the static launcher was introduced in
> [JDK-8339480](https://bugs.openjdk.org/browse/JDK-8339480), due to time and
> resource constraints, it was only working properly on Linux and macOS, while
> the Windows port compiled but
On Thu, 19 Dec 2024 16:27:30 GMT, Magnus Ihse Bursie wrote:
> We need to raise the abstraction of the SetupBuildLauncher API, to prepare
> for static launchers. We should specify the desired outcome, not what flags
> we should add. This can be seen as the last part of
> [JDK-8141444](https://b
On Tue, 26 Nov 2024 17:17:09 GMT, Magnus Ihse Bursie wrote:
>> As a prerequisite for Hermetic Java, we need a statically linked `java`
>> launcher. It should behave like the normal, dynamically linked `java`
>> launcher, except that all JDK native libraries should be statically, not
>> dynamic
On Mon, 18 Nov 2024 15:12:12 GMT, Magnus Ihse Bursie wrote:
>> As a prerequisite for Hermetic Java, we need a statically linked `java`
>> launcher. It should behave like the normal, dynamically linked `java`
>> launcher, except that all JDK native libraries should be statically, not
>> dynamic
On Thu, 31 Oct 2024 13:29:35 GMT, Claes Redestad wrote:
> Benchmarks using Indify was added to the JMH microbenchmarks corpus in the
> JDK 8 timeframe. This adds overhead to the microbenchmarks build and has been
> blocking/slowing progress on some indy-based prototyping as the indify tool
> i
On Thu, 31 Oct 2024 10:52:22 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 29 Oct 2024 16:15:30 GMT, Pavel Rappo wrote:
>> Prepare for JDK 25.
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add forgotten .jcheck/conf
Marked as reviewed by erikj (Reviewer).
-
PR Review: https
On Mon, 28 Oct 2024 18:58:51 GMT, Aleksey Shipilev wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>> T
On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie wrote:
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This
On Fri, 25 Oct 2024 16:29:52 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Mon, 14 Oct 2024 23:26:04 GMT, Brian Burkhalter wrote:
> > I'm taking this fix for a spin over night in the environment where I
> > noticed the problem.
>
> I'll hold off integrating until that is over.
Test successful, thanks for fixing this!
-
PR Comment: https://git.openjdk
On Mon, 14 Oct 2024 18:02:44 GMT, Brian Burkhalter wrote:
>> Change property `test.src` to `test.dir`.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8341997: Replace test.dir property with CWD
I'm taking this fix for
On Mon, 14 Oct 2024 17:55:49 GMT, Brian Burkhalter wrote:
> The property `test.dir` has been used as a convention but I've no problem
> with changing it to the CWD.
I wasn't aware, but if it's convention, I'm ok with it.
-
PR Comment: https://git.openjdk.org/jdk/pull/21503#issueco
On Mon, 14 Oct 2024 18:02:44 GMT, Brian Burkhalter wrote:
>> Change property `test.src` to `test.dir`.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8341997: Replace test.dir property with CWD
Marked as reviewed by e
On Mon, 14 Oct 2024 17:37:01 GMT, Brian Burkhalter wrote:
> Change property `test.src` to `test.dir`.
I can't find any reference to `test.dir` in the jtreg documentation. I would
expect to see it here https://openjdk.org/jtreg/tag-spec.html#testvars. My
understanding is that you should just us
On Thu, 10 Oct 2024 12:25:53 GMT, Kevin Rushforth wrote:
>> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it
>> with JavaFX instead.
>>
>> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR
>> openjdk/jfx#1529 for the JavaFX PR that will include the mo
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
On Fri, 30 Aug 2024 11:35:51 GMT, Magnus Ihse Bursie wrote:
>> Currently, we issue -Wno-unused for all files in clang, which is a rather
>> big sledgehammer to get rid of some warnings that proliferate in a few areas
>> of the build.
>>
>> We should instead leave -Wunused turned on (as done by
On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie wrote:
> Currently, we issue -Wno-unused for all files in clang, which is a rather big
> sledgehammer to get rid of some warnings that proliferate in a few areas of
> the build.
>
> We should instead leave -Wunused turned on (as done by -Wal
On Wed, 28 Aug 2024 15:17:52 GMT, Magnus Ihse Bursie wrote:
>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big
>> sledgehammer to get rid of some warnings that proliferate in a few areas of
>> the build.
>>
>> We should instead leave -Wunused turned on (as done by -
On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes wrote:
> I understand the cost overhead experienced by any individual Java run may be
> lost in the noise, but it still impacts every single Java run just to save
> some time/resources for the handful of builders of statically linked VMs. I
> am n
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the sta
On Thu, 2 May 2024 09:48:51 GMT, Christian Stein wrote:
> Please review the change to update to using `jtreg` **7.4**.
>
> 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 `requiredV
On Fri, 7 Jun 2024 12:37:48 GMT, Julian Waters wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> delete extra empty trailing blank line in
>> test/jdk/java/rmi/reliability/benchmark/bench/Makefile
>
> test/jdk/java/rmi
On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote:
>> Hi all,
>> This PR several extra empty spaces and extra empty lines in several
>> Makefiles. It's trivial fix, no risk.
>>
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional
> commit since the last revi
On Wed, 5 Jun 2024 17:31:44 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> i
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote:
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
Marked as reviewed by erikj (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19537#pull
On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie wrote:
> The original way of building static libraries in the JDK was to use the
> configure argument --enable-static-build, which set the value of the make
> variable STATIC_BUILD. (Note that this is not the same as the source code
> defini
On Fri, 24 May 2024 12:16:25 GMT, Ludvig Janiuk wrote:
> Adding commetns to clarify that the failure_handler selftests are intended to
> be run manually. Ideally this would include a more thorough description of
> the exepcted outputs, but this is what I have time to add right now.
test/failur
On Fri, 17 May 2024 21:57:00 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from any
On Fri, 17 May 2024 05:51:31 GMT, Alan Bateman wrote:
>> Joe Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove jaxp-compat.properties from the list
>
> make/modules/java.xml/Copy.gmk line 37:
>
>> 35: JAXPPROPFILE_TARGET_FILES
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from any
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Thu, 4 Apr 2024 15:24:53 GMT, Severin Gehwolf wrote:
>> make/CompileToolsJdk.gmk line 50:
>>
>>> 48: EXCLUDES := \
>>> 49: build/tools/classlist \
>>> 50: build/tools/runtimeimagelinkdeltaproducer \
>>
>> This directory name is comically long. I guess that's not really a
On Thu, 4 Apr 2024 11:12:43 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> i
On Mon, 18 Mar 2024 18:40:36 GMT, Severin Gehwolf wrote:
> What I mean to convey is that how the directory tree in `images/jdk` looks
> like shouldn't change based on the `--enable-linkable-runtime-image`
> configure flag. That is, there will be a `images/jdk/jmods` folder unless
> `--disable-
On Thu, 14 Mar 2024 20:54:32 GMT, Mandy Chung wrote:
> About the configure options,
>
> ```
> --enable-keep-packaged-modules
> enable keeping of packaged modules in jdk image
> [enabled]
> --enable-runtime-link-image
> enable producing an
On Thu, 14 Mar 2024 14:27:47 GMT, Severin Gehwolf wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment in autoconf file
>
> make/Images.gmk line 33:
>
>> 31: include Modules.gmk
>> 32: include Utils.gmk
On Thu, 14 Mar 2024 14:24:57 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Wed, 13 Mar 2024 17:11:25 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>> replacing
On Wed, 13 Mar 2024 11:59:36 GMT, Magnus Ihse Bursie wrote:
>> As part of the ongoing effort to enable jcheck whitespace checking to all
>> text files, it is now time to address assembly (.S) files. The hotspot
>> assembly files were fixed as part of the hotspot mapfile removal, so only a
>> s
On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>> replacing
On Mon, 11 Mar 2024 18:36:57 GMT, Aleksey Shipilev wrote:
> > If you really want to require an exact match for jspawnhelper, then these 4
> > numbers aren't necessarily enough, but a rather arbitrarily chosen
> > approximation.
>
> I think for our purposes, a version number quadruplet is enoug
On Mon, 11 Mar 2024 17:46:14 GMT, Chad Rakoczy wrote:
> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>
> Updates jspawnhelper to check that JDK version and jspawnhelper version are
> the same. Updates test to include check for version. Also tested manually by
> replacing jspa
On Tue, 27 Feb 2024 15:23:09 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Fri, 8 Mar 2024 17:36:33 GMT, Severin Gehwolf wrote:
>> That was modelled similar to `jdk_jlink` target. It also does the removal.
>> When building with `--enable-runtime-link-image`, the flow is:
>>
>>
>> 1. Link the initial jdk image (current `images/jdk`). Output is
>> $(RL_INTERMEDIATE
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> T
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote:
> We should match the building of jspawnhelper in
> make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
> src/java.base/unix/classes/java/lang/ProcessImpl.java.
>
> Granted, the list of OSes in the makefile amo
On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie wrote:
>> Currently, our symbol visibility handling for tests are sloppy; we only
>> handle it properly on Windows. We need to bring it up to the same levels as
>> product code. This is a prerequisite for
>> [JDK-8327045](https://bugs.openjdk
On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson wrote:
> Executables and dynamic libraries on Linux can encode a search path that the
> dynamic linker will use when looking up library dependencies, generally
> referred to as an "rpath". In the JDK we use this with the $ORIGI
On Tue, 5 Mar 2024 07:16:10 GMT, David Holmes wrote:
> Thanks for the further explanation and adding the comment.
>
> LGTM.
Thanks! Does the release note also looks ok? I understand it needs to be
reviewed together with the PR.
-
PR Comment: https://git.openjdk.org/jdk/pull/18050
that we explicitly configure the JDK build to set RPATH instead of
> RUNPATH for Linux binaries. This is done with the linker flag
> "--disable-new-dtags".
Erik Joelsson has updated the pull request incrementally with one additional
commit since the last revision:
bug ref
On Mon, 4 Mar 2024 14:53:21 GMT, Magnus Ihse Bursie wrote:
>> make/autoconf/flags-cflags.m4 line 40:
>>
>>> 38: # Default works for linux, might work on other platforms as well.
>>> 39: SHARED_LIBRARY_FLAGS='-shared'
>>> 40: SET_EXECUTABLE_ORIGIN='-Wl,-rpath,\$$ORIGIN[$]1
>>> -Wl,--
that we explicitly configure the JDK build to set RPATH instead of
> RUNPATH for Linux binaries. This is done with the linker flag
> "--disable-new-dtags".
Erik Joelsson has updated the pull request incrementally with one additional
commit since the last revision:
Add comm
On Sun, 3 Mar 2024 22:09:51 GMT, David Holmes wrote:
> I find it somewhat odd that we seem to be add odds with the general
> programming community when it comes to this behaviour. Giving precedence to
> `LD_LIBRARY_PATH` is the new behaviour, enabled via `--enable-new-dtags`; and
> at some poi
On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda wrote:
> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
> automatically granted the native access. I am working on an upgrade of JLine
> inside the `jdk.internal.le` module, and I would like to replace the current
> native
that we explicitly configure the JDK build to set RPATH instead of
> RUNPATH for Linux binaries. This is done with the linker flag
> "--disable-new-dtags".
Erik Joelsson has updated the pull request incrementally with one additional
commit since the last revision:
Use @require
On Fri, 1 Mar 2024 06:30:14 GMT, David Holmes wrote:
>> Erik Joelsson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use @requires in test
>
> test/jdk/tools/launcher/RunpathTest.java line 27:
>
>&
On Thu, 29 Feb 2024 06:34:42 GMT, David Holmes wrote:
> I can imagine it could be used to allow "hot patching" of the installed
> JDK/JRE. Whether anyone has ever needed to do so is another matter. I suggest
> at least adding a Release Note.
Added release note.
-
PR Comment: http
Executables and dynamic libraries on Linux can encode a search path that the
dynamic linker will use when looking up library dependencies, generally
referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to
set search paths relative to the location of the binary itself. Typic
On Tue, 27 Feb 2024 15:23:09 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato wrote:
> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
> `COMPAT` locale data was introduced for applications' migratory purposes
> transitioning to `CLDR`. It is becoming a technical debt and now is the time
> to remov
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This is better described by a
> sp
On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie wrote:
>> Since jcheck only checks file in a commit, there is a possibility of us
>> getting files in the repository that would not be accepted by jcheck. This
>> can happen when extending the set of files checked by jcheck, or if jcheck
>>
On Thu, 15 Feb 2024 12:26:11 GMT, Magnus Ihse Bursie wrote:
>> Since jcheck only checks file in a commit, there is a possibility of us
>> getting files in the repository that would not be accepted by jcheck. This
>> can happen when extending the set of files checked by jcheck, or if jcheck
>>
On Fri, 9 Feb 2024 13:42:02 GMT, Magnus Ihse Bursie wrote:
>> This is an attempt to finally implement the idea brought forward in
>> JDK-8295729: Properties files is essentially source code. It should have
>> the same whitespace checks as all other source code, so we don't get
>> spurious tra
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote:
> Inspired by (the later backed-out)
> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
> enable `-Wpedantic` for clang. This has already found some irregularities in
> the code, like mistakenly using `#import`
On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote:
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
Marked as reviewed by erikj (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/17677#pullrequ
On Tue, 16 Jan 2024 16:31:32 GMT, Henry Jen wrote:
> CPU24_01 fixes.
Marked as reviewed by erikj (Reviewer).
-
PR Review: https://git.openjdk.org/jdk22/pull/83#pullrequestreview-1826185706
On Tue, 16 Jan 2024 19:05:44 GMT, Henry Jen wrote:
>> CPU24_01 fixes.
>
> Henry Jen has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brought in
> by the merge/rebase. The pull request contains eight additiona
On Fri, 12 Jan 2024 15:17:42 GMT, Per Minborg wrote:
> This PR proposes to remove the snippet files in
> `java/lang/foreign/snippet-files` from the build.
make/modules/java.base/Java.gmk line 41:
> 39: java/lang/classfile/snippet-files \
> 40: java/lang/classfile/components/snippet-fil
On Thu, 11 Jan 2024 14:17:39 GMT, Erik Joelsson wrote:
>> In principle, I think tests should be executed from their corresponding
>> test-support directory. (I think there is some JBS issue for this that's
>> been around for some while.) The rationale is that this is a
On Thu, 11 Jan 2024 11:23:55 GMT, Magnus Ihse Bursie wrote:
> In principle, I think tests should be executed from their corresponding
> test-support directory. (I think there is some JBS issue for this that's been
> around for some while.) The rationale is that this is a good directory for
> a
On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad wrote:
> JMH microbenchmarks may have dependencies on artifacts in the test image
> outside of the benchmarks.jar. This includes native libraries (built into
> `$TEST_IMAGE/micro/native`) and may soon include other test libraries like
> wb.jar (
1 - 100 of 213 matches
Mail list logo
