Re: RFR: 8325878: Require minimum Clang version 13

2024-03-04 Thread Kim Barrett
On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett wrote: > Please review this change that updates the minimum supported version of Clang > to be used for building OpenJDK from 3.5 to 13. > > This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for > that. A minimum of Clang 13 als

Re: RFR: 8327173: HotSpot Style Guide needs update regarding nullptr vs NULL [v2]

2024-03-04 Thread David Holmes
On Tue, 5 Mar 2024 07:12:09 GMT, Kim Barrett wrote: >> Please review this change to update the HotSpot Style Guide's discussion of >> nullptr and its use. >> >> I suggest this is an editorial rather than substantive change to the style >> guide. As such, the normal HotSpot PR process can be use

Integrated: 8325881: Require minimum gcc version 10

2024-03-04 Thread Kim Barrett
On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett wrote: > Please review this change that updates the minimum supported version of gcc > to be used for building OpenJDK from 6.0 to 10.0. > > This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for > that. A minimum of gcc 10 also

Re: RFR: 8325881: Require minimum gcc version 10

2024-03-04 Thread Kim Barrett
On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett wrote: > Please review this change that updates the minimum supported version of gcc > to be used for building OpenJDK from 6.0 to 10.0. > > This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for > that. A minimum of gcc 10 also

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v4]

2024-03-04 Thread David Holmes
On Mon, 4 Mar 2024 23:44:14 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 $ORIGIN feature >> to s

Re: RFR: 8327173: HotSpot Style Guide needs update regarding nullptr vs NULL [v2]

2024-03-04 Thread Kim Barrett
On Mon, 4 Mar 2024 09:52:15 GMT, Aleksey Shipilev wrote: >> Kim Barrett has updated the pull request incrementally with one additional >> commit since the last revision: >> >> respond to shipilev comments > > doc/hotspot-style.md line 738: > >> 736: expressions with value zero. C++14 replac

Re: RFR: 8327173: HotSpot Style Guide needs update regarding nullptr vs NULL [v2]

2024-03-04 Thread Kim Barrett
On Mon, 4 Mar 2024 18:01:35 GMT, Vladimir Kozlov wrote: >> I think it would be enough to write 1..2 sentences about this, and then >> defer to N2431 already linked here for more details. > > I agree with Aleksey. Good point. I decided just referring to the paper for rationale is sufficient. -

Re: RFR: 8327173: HotSpot Style Guide needs update regarding nullptr vs NULL [v2]

2024-03-04 Thread Kim Barrett
> Please review this change to update the HotSpot Style Guide's discussion of > nullptr and its use. > > I suggest this is an editorial rather than substantive change to the style > guide. As such, the normal HotSpot PR process can be used for this change. Kim Barrett has updated the pull reques

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK [v6]

2024-03-04 Thread Joe Wang
On Mon, 4 Mar 2024 19:07:44 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 re

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v4]

2024-03-04 Thread Erik Joelsson
> 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 itsel

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v45]

2024-03-04 Thread Jonathan Gibbons
> Please review a patch to add support for Markdown syntax in documentation > comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` > libra

Re: RFR: 8174269: Remove COMPAT locale data provider from JDK [v6]

2024-03-04 Thread Naoto Sato
> 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 remove it (we've been emitting a warning at JVM startup sin

Re: RFR: 8327173: HotSpot Style Guide needs update regarding nullptr vs NULL

2024-03-04 Thread Vladimir Kozlov
On Mon, 4 Mar 2024 09:51:16 GMT, Aleksey Shipilev wrote: >> doc/hotspot-style.md line 730: >> >>> 728: Use `nullptr` >>> 729: >>> ([n2431](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf)) >>> 730: rather than `NULL`. Don't use (constant expression or literal) 0 for >>> poin

Re: RFR: 8327218: Add an ability to specify modules which should have native access enabled

2024-03-04 Thread ExE Boss
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

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4]

2024-03-04 Thread Claudio Nieder
On Tue, 27 Feb 2024 11:19:59 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 >

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v44]

2024-03-04 Thread Pavel Rappo
On Mon, 4 Mar 2024 14:40:06 GMT, Pavel Rappo wrote: > I have a test case to report. The following results in no `@param` > information being rendered, which I think is a bug: > > ``` > /// Hello, _Markdown_ world! > /// > /// > /// @param hello > /// > /// > public class C { } > ``` Scratch

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4]

2024-03-04 Thread Magnus Ihse Bursie
On Mon, 4 Mar 2024 11:45:59 GMT, Julian Waters wrote: > I do hope that dropping ccache support isn't something that's planned though > :( Not really. The benefit of dropping it is quite small, and there might be use cases where it helps. But I think we should perhaps be more explicit in the

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v3]

2024-03-04 Thread Magnus Ihse Bursie
On Mon, 4 Mar 2024 14:57:44 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 $ORIGIN feature >> to s

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]

2024-03-04 Thread Erik Joelsson
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,--

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]

2024-03-04 Thread Magnus Ihse Bursie
On Sun, 3 Mar 2024 22:12:19 GMT, David Holmes wrote: >> Erik Joelsson has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use @requires in test > > make/autoconf/flags-cflags.m4 line 40: > >> 38: # Default works for linux, might work on

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v3]

2024-03-04 Thread Erik Joelsson
> 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 itsel

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]

2024-03-04 Thread Erik Joelsson
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

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v44]

2024-03-04 Thread Pavel Rappo
On Fri, 1 Mar 2024 21:49:29 GMT, Jonathan Gibbons wrote: >> Please review a patch to add support for Markdown syntax in documentation >> comments, as described in the associated JEP. >> >> Notable features: >> >> * support for `///` documentation comments in `JavaTokenizer` >> * new module `jd

Re: RFR: 8327218: Add an ability to specify modules which should have native access enabled

2024-03-04 Thread Erik Joelsson
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

Re: RFR: 8327218: Add an ability to specify modules which should have native access enabled

2024-03-04 Thread Maurizio Cimadamore
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

RFR: 8327218: Add an ability to specify modules which should have native access enabled

2024-03-04 Thread Jan Lahoda
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 bindings with FFM-based bindings (which are now somewhat pro

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4]

2024-03-04 Thread Julian Waters
On Mon, 4 Mar 2024 12:58:28 GMT, Claudio Nieder wrote: > > Could I trouble you to mention what exactly was different? > > No trouble at all. > > `CCACHE_BASEDIR=/tmp/bceaed6d/jdk/`is completely missing. (The directory is > where I checked out OpenJDK) > > `CCACHE_SLOPPINESS` has the value `pc

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4]

2024-03-04 Thread Claudio Nieder
On Mon, 4 Mar 2024 11:45:59 GMT, Julian Waters wrote: > Could I trouble you to mention what exactly was different? No trouble at all. `CCACHE_BASEDIR=/tmp/bceaed6d/jdk/`is completely missing. (The directory is where I checked out OpenJDK) `CCACHE_SLOPPINESS` has the value `pch_defines,time_m

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4]

2024-03-04 Thread Julian Waters
On Mon, 4 Mar 2024 11:28:02 GMT, Magnus Ihse Bursie wrote: > > I wonder if it's the SetupToolchain changes that has caused this. ccache is > > collapsed into CC and CXX to my knowledge > > Yeah, it must have been. Would you like to take a look at it? Otherwise I'll > file a bug and fix it. Bre

Re: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4]

2024-03-04 Thread Magnus Ihse Bursie
On Mon, 4 Mar 2024 06:42:30 GMT, Julian Waters wrote: > I wonder if it's the SetupToolchain changes that has caused this. ccache is > collapsed into CC and CXX to my knowledge Yeah, it must have been. Would you like to take a look at it? Otherwise I'll file a bug and fix it. Breaking ccache wa

Re: RFR: 8327173: HotSpot Style Guide needs update regarding nullptr vs NULL

2024-03-04 Thread Aleksey Shipilev
On Mon, 4 Mar 2024 08:38:09 GMT, Kim Barrett wrote: > Please review this change to update the HotSpot Style Guide's discussion of > nullptr and its use. > > I suggest this is an editorial rather than substantive change to the style > guide. As such, the normal HotSpot PR process can be used for

Re: RFR: 8327173: HotSpot Style Guide needs update regarding nullptr vs NULL

2024-03-04 Thread Aleksey Shipilev
On Mon, 4 Mar 2024 08:41:46 GMT, Kim Barrett wrote: >> Please review this change to update the HotSpot Style Guide's discussion of >> nullptr and its use. >> >> I suggest this is an editorial rather than substantive change to the style >> guide. As such, the normal HotSpot PR process can be use

RFR: 8327173: HotSpot Style Guide needs update regarding nullptr vs NULL

2024-03-04 Thread Kim Barrett
Please review this change to update the HotSpot Style Guide's discussion of nullptr and its use. I suggest this is an editorial rather than substantive change to the style guide. As such, the normal HotSpot PR process can be used for this change. - Commit messages: - update nullptr

Re: RFR: 8327173: HotSpot Style Guide needs update regarding nullptr vs NULL

2024-03-04 Thread Kim Barrett
On Mon, 4 Mar 2024 08:38:09 GMT, Kim Barrett wrote: > Please review this change to update the HotSpot Style Guide's discussion of > nullptr and its use. > > I suggest this is an editorial rather than substantive change to the style > guide. As such, the normal HotSpot PR process can be used for