On Tue, 5 Mar 2024 14:19:14 GMT, Erik Joelsson wrote:
> Does the release note also looks ok?
Yes.
> Is there any process to formally review release notes?
No. Typically just add a comment to the RN sub-task indicating it is okay. My
comment, that I had made some minor changes was meant as an
On Tue, 5 Mar 2024 16:13:14 GMT, Jan Lahoda wrote:
>> I see. I then misunderstood a part of the PR description.
>
> I believe we could technically reuse the list for boot/platform modules. But,
> the intent here is to provide more control over the modules with native
> access, not only being
On Tue, 5 Mar 2024 18:43:44 GMT, Alan Bateman wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Apply suggestions from code review
>>
>> Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
>>
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 $ORIGIN feature to
> set
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
On Mon, 4 Mar 2024 15:16:32 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
On Tue, 5 Mar 2024 12:44:10 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
>>
On Tue, 5 Mar 2024 17:50:09 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
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
On Tue, 5 Mar 2024 06:44:52 GMT, Joe Wang wrote:
>> Naoto Sato 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 44 additional
>> commits since
> 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
On Tue, 27 Feb 2024 13:55:53 GMT, Ludvig Janiuk wrote:
> Clarifying text in `make help` output on how to list variables for e.g.
> JTREG='...'.
This pull request has now been integrated.
Changeset: c6641c7d
Author:Ludvig Janiuk
Committer: Magnus Ihse Bursie
URL:
On Tue, 27 Feb 2024 13:55:53 GMT, Ludvig Janiuk wrote:
> Clarifying text in `make help` output on how to list variables for e.g.
> JTREG='...'.
Marked as reviewed by ihse (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/18028#pullrequestreview-1917514719
On Tue, 5 Mar 2024 14:14:15 GMT, Jaikiran Pai wrote:
>>> to make the intention clear as well as reduce the chances of missing some
>>> boot or platform module in this NATIVE_ACCESS_MODULES?
>>
>> The list to be be granted native access is a subset, it shouldn't be granted
>> all modules
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
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:
On Tue, 5 Mar 2024 14:01:55 GMT, Alan Bateman wrote:
>> make/conf/module-loader-map.conf line 95:
>>
>>> 93: #
>>> 94:
>>> 95: NATIVE_ACCESS_MODULES= \
>>
>> Hello Jan, does this make configuration allow for something like:
>>
>>
>> NATIVE_ACCESS_MODULES= ${BOOT_MODULES} \
>>
On Tue, 5 Mar 2024 13:42:32 GMT, Jaikiran Pai wrote:
> to make the intention clear as well as reduce the chances of missing some
> boot or platform module in this NATIVE_ACCESS_MODULES?
The list to be be granted native access is a subset, it shouldn't be granted
all modules mapped to the boot
On Tue, 5 Mar 2024 12:44:10 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
>>
On Tue, 5 Mar 2024 12:44:10 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
>>
On Tue, 5 Mar 2024 12:41:18 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
>>
> 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
On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++. SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
>
> I need someone from the aix-ppc
On Tue, 5 Mar 2024 09:10:50 GMT, Joachim Kern wrote:
>>> > What does this mean? That you are not using xlc at all? Or is it clang
>>> > but still with an xlc frontend, so all xlc flags etc need to stay?
>>>
>>> The `xlc` toolchain is for the compiler versions up to 16 (xlclang++); the
>>>
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
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
On Tue, 5 Mar 2024 08:41:00 GMT, Kim Barrett wrote:
> > > What does this mean? That you are not using xlc at all? Or is it clang
> > > but still with an xlc frontend, so all xlc flags etc need to stay?
> >
> >
> > The `xlc` toolchain is for the compiler versions up to 16 (xlclang++); the
> >
On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++. SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
>
> I need someone from the aix-ppc
On Thu, 15 Feb 2024 11:10:32 GMT, Joachim Kern wrote:
> > What does this mean? That you are not using xlc at all? Or is it clang but
> > still with an xlc frontend, so all xlc flags etc need to stay?
>
> The `xlc` toolchain is for the compiler versions up to 16 (xlclang++); the
> `clang`
On Tue, 5 Mar 2024 07:20:33 GMT, Kim Barrett wrote:
> Thanks for reviews/responses. I'll go ahead with integration. We won't be
> reliant on the new version immediately, so we can still reconsider if it
> causes someone problems and they bring it up soon-ish.
Well, no I'm not. I don't want
30 matches
Mail list logo
