On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
>
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
On Tue, 5 Mar 2024 18:16:51 GMT, Vladimir Kozlov wrote:
>> Kim Barrett 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 three additional
>>
> 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
> 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`
>
This is a patch that:
a) upgrades the JLine inside the JDK to 3.25.1
b) since the new version of JLine has a FFM backend, our custom native backends
are removed, and replaced with the FFM backend
Some changes had to be made to the original JLine in order to fit into the JDK.
Most of them were
On Tue, 5 Mar 2024 18:54:55 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>
>>
> 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 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
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
> 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 also obtains a critical bug fix for the
> [[noreturn]]
>
> 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 porters to test and review the change.
Kim Barrett has
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 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 Wed, 6 Mar 2024 17:28:01 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Only show runtime image suffix for JDK modules
>
> make/ToolsJdk.gmk line 88:
>
>> 86:
On Wed, 6 Mar 2024 19:00:19 GMT, Alan Bateman wrote:
>> Native access is needed for modules which calls restricted methods [1].
>> AFAICT, java.base, java.desktop and jdk.incubator.vector use
>> java.lang.foreign but I don't know if they call restricted methods or not.
>>
>>
On Wed, 6 Mar 2024 18:00:25 GMT, Mandy Chung wrote:
> Native access is needed for modules which calls restricted methods [1].
In time, we'll need it for modules using JNI too. We can do this trimming in
another PR to avoid Jan getting pulled into deeply.
-
PR Review Comment:
On Wed, 6 Mar 2024 17:17:28 GMT, Magnus Ihse Bursie wrote:
> I agree that it is good to get rid of this. However, the reason it has stuck
> around for so long is, eh, that it has been around for so long, so it is a
> bit unclear what or who could be relying on this.
The example I know is to
On Wed, 6 Mar 2024 15:02:07 GMT, Jan Lahoda wrote:
>>> Many of these modules do not need native access in the current
>>> implementation.
>>
>> In addition this will eventually need jlink support. I view the change to
>> ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules()
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 Tue, 5 Mar 2024 08:24:20 GMT, Kim Barrett wrote:
> I don't want to integrate this until the minimum aix-ppc toolchain has been
> updated
@kimbarrett Is anyone working on that problem?
-
PR Comment: https://git.openjdk.org/jdk/pull/17862#issuecomment-1981399543
On Wed, 6 Mar 2024 15:24:59 GMT, Andrew John Hughes wrote:
>> I'm fine with this change. I wasn't around when this was introduced, but my
>> guess is that it was relevant back when Hotspot and the rest of the JDK were
>> often built separately. We have the username in the default $OPT string
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
>
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
>
On Wed, 6 Mar 2024 00:56:16 GMT, Jaikiran Pai wrote:
>> 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 able to add to the list, but also remove from the
>> list.
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 Wed, 6 Mar 2024 13:57:37 GMT, Erik Joelsson wrote:
> I'm fine with this change. I wasn't around when this was introduced, but my
> guess is that it was relevant back when Hotspot and the rest of the JDK were
> often built separately. We have the username in the default $OPT string for
>
On Wed, 6 Mar 2024 09:19:44 GMT, Alan Bateman wrote:
>> Many of these modules do not need native access in the current
>> implementation. Should this list be trimmed to list the ones that need
>> native access in the current implementation?
>
>> Many of these modules do not need native
On Tue, 5 Mar 2024 13:58:50 GMT, Jaikiran Pai 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, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
>
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
>>
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
>>
> 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.org/browse/JDK-8327045), which in turn is
> a building block
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
>
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
>
On Wed, 6 Mar 2024 11:33:30 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
>
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.org/browse/JDK-8327045), which in turn is a
building block for
The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
internal version string since before the JDK was open-sourced, so the reasoning
for this is not in the public history. See
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
On Tue, 5 Mar 2024 22:44:20 GMT, Mandy Chung wrote:
> Many of these modules do not need native access in the current implementation.
In addition this will eventually need jlink support. I view the change to
ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules() as
very
39 matches
Mail list logo
