On Sun, 21 Jan 2024 19:50:16 GMT, Phil Race wrote:
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
> See my comment
> "like in
On Thu, 21 Mar 2024 15:33:21 GMT, Aleksey Shipilev wrote:
> Debian "unstable" is currently undergoing t64 (hello, Y2038) transition,
> which breaks "sid" repo that we use for debootstrapping RISC-V very often.
> This is seen across multiple repositories, and requires everyone to look
>
> 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`
>
> 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`
>
On Wed, 20 Mar 2024 18:55:38 GMT, Jan Lahoda wrote:
>> 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
On Thu, 21 Mar 2024 16:57:40 GMT, Aleksey Shipilev wrote:
> Noticed this while fixing other GHA issues.
>
> We pass build JDK to cross-compilation jobs, which makes them dependent on
> Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS
> there is no need for build JDK,
On Thu, 21 Mar 2024 11:49:11 GMT, Magnus Ihse Bursie wrote:
> This is the first step of several, in which I will clean up the native
> compilation code as used by modules. In this first step `java.base`,
> `java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since
> they
On Thu, 21 Mar 2024 15:43:28 GMT, Magnus Ihse Bursie wrote:
>>> > The problem I see is that J. Random Java User has no way to know if SLEEF
>>> > is making their program faster without running benchmarks. They'll put
>>> > SLEEF somewhere and hope that Java uses it.
>>>
>>> Please kindly
Noticed this while fixing other GHA issues.
We pass build JDK to cross-compilation jobs, which makes them dependent on
Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS there
is no need for build JDK, and therefore no need for the dependency. Untying
cross-compilation
On Thu, 21 Mar 2024 16:57:40 GMT, Aleksey Shipilev wrote:
> Noticed this while fixing other GHA issues.
>
> We pass build JDK to cross-compilation jobs, which makes them dependent on
> Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS
> there is no need for build JDK,
Debian "unstable" is currently undergoing t64 (hello, Y2038) transition, which
breaks "sid" repo that we use for debootstrapping RISC-V very often. This is
seen across multiple repositories, and requires everyone to look through GHA
failures all the time. This PR tries to fix this: if
On Tue, 19 Mar 2024 17:15:29 GMT, Andrew Haley wrote:
>>> If there was some kind of plan, with evidence of the intention to do
>>> something to get this valuable tech into people's hands in a form they can
>>> use, sure. But as you can tell, I think this may rot because no one will be
>>>
On Tue, 19 Mar 2024 17:15:29 GMT, Andrew Haley wrote:
>>> If there was some kind of plan, with evidence of the intention to do
>>> something to get this valuable tech into people's hands in a form they can
>>> use, sure. But as you can tell, I think this may rot because no one will be
>>>
On Thu, 21 Mar 2024 15:28:23 GMT, Magnus Ihse Bursie wrote:
>>> First question, do this class really need to be in a separate module? (I'm
>>> afraid the answer is "yes" but I need to ask it anyway).
>>
>> Yes, because it uses the `Plugin` ServiceLoader extension using the boot
>>
On Thu, 21 Mar 2024 15:27:06 GMT, Severin Gehwolf wrote:
>> make/Images.gmk line 131:
>>
>>> 129: # in FixPath call in order to avoid needing to use strip.
>>> 130: RL_JIMAGE_PATH_ARG := $(call
>>> FixPath,$(JDK_LINK_OUTPUT_DIR)/lib/modules)
>>> 131: RL_MOD_PATH_ARG := $(call
On Thu, 21 Mar 2024 14:54:15 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move CreateLinkableRuntimePlugin to build folder
>>
>> Keep runtime link supporting classes in package
On Tue, 19 Mar 2024 16:55:14 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, 19 Mar 2024 16:55:14 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, 19 Mar 2024 16:55:14 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 Thu, 21 Mar 2024 11:49:11 GMT, Magnus Ihse Bursie wrote:
> This is the first step of several, in which I will clean up the native
> compilation code as used by modules. In this first step `java.base`,
> `java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since
> they
This is the first step of several, in which I will clean up the native
compilation code as used by modules. In this first step `java.base`,
`java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since they
require more work. The changes in the remaining modules are trivial by
On Wed, 20 Mar 2024 16:20:36 GMT, Magnus Ihse Bursie wrote:
> In [JDK-8328157](https://bugs.openjdk.org/browse/JDK-8328157), I rewrote the
> logic to replace -MD with -MT for compiling on Windows. Unfortunately, I
> mistakenly set -MT for all compilers, not just for visual studio.
This pull
> Hi, please consider.
>
> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
> Tested with gcc and clang, and llvm and binutils backend.
>
> I didn't find any use of the "DLL_ENTRY", so I removed it.
>
> Thanks, Robbin
Robbin Ehn has updated the pull request
On Thu, 21 Mar 2024 06:02:56 GMT, David Holmes wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any use of the "DLL_ENTRY", so I removed it.
>>
>>
On Wed, 20 Mar 2024 16:17:36 GMT, Robbin Ehn wrote:
> Hi, please consider.
>
> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
> Tested with gcc and clang, and llvm and binutils backend.
>
> I didn't find any use of the "DLL_ENTRY", so I removed it.
>
> Thanks,
25 matches
Mail list logo
