On Thu, 23 May 2024 18:52:53 GMT, Alan Bateman wrote:
> Yes, I want to help you get this one over the line.
Thanks! Appreciate that.
-
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2133375454
On Thu, 23 May 2024 16:42:39 GMT, Severin Gehwolf wrote:
> Do you think you'll be able to review this next week?
Yes, I want to help you get this one over the line.
-
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2127828050
On Thu, 16 May 2024 13:47:20 GMT, Alan Bateman wrote:
>>> If I understand you correctly, this would be no longer a build-time only
>>> approach to produce the "linkable runtime"? It would be some-kind of
>>> jlink-option driven approach (as it would run some code that should only
>>> run when
On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote:
>>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going
>>> > into the direction you had envisioned? Any more blockers? The CSR should
>>> > be up-to-date and is open for review as well. If no more blockers I'll go
On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote:
>>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going
>>> > into the direction you had envisioned? Any more blockers? The CSR should
>>> > be up-to-date and is open for review as well. If no more blockers I'll go
On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote:
> I think it continues to build time, it's just using some hidden jlink option.
> So yes, it similar to a previous iteration except that it doesn't run as a
> plugin the pipeline and the delta goes to the lib directory.
OK. If a hidden
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung 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, 16 Apr 2024 11:59:12 GMT, Severin Gehwolf wrote:
> If I understand you correctly, this would be no longer a build-time only
> approach to produce the "linkable runtime"? It would be some-kind of
> jlink-option driven approach (as it would run some code that should only run
> when
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung 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 Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung 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 Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung 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 Thu, 21 Mar 2024 15:35:06 GMT, Severin Gehwolf wrote:
>> Ok, fine. Will the new solution still include a build-time only tool?
>
> Yes, but I'll likely go with the interim solution and that would only require
> the a single "driver" class in the build tree with a `main` method.
Now it's no
On Thu, 21 Mar 2024 15:30:01 GMT, Magnus Ihse Bursie wrote:
>> Thanks! This will also likely change. I'm thinking of just generating the
>> diff file and putting it into `lib/` of the JDK image. That avoids needing
>> to call this build-time only jlink plugin and this `FixPath` magic.
>
> I
On Thu, 21 Mar 2024 15:29:45 GMT, Severin Gehwolf wrote:
>> make/Images.gmk line 145:
>>
>>> 143: $(eval $(call SetupJavaCompilation, BUILD_JDK_RUNLINK_CLASSES, \
>>> 144: COMPILER := buildjdk, \
>>> 145: DISABLED_WARNINGS := try, \
>>
>> Why do we get warnings in the java code?
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung wrote:
> Thanks for the investigation w.r.t. extending jimage. It does not seem worth
> the effort in pursuing the support of adding resources to an existing jimage
> file. To me, putting the diff data under `lib` directory as a private file is
> a
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 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 Wed, 20 Mar 2024 10:24:23 GMT, Severin Gehwolf wrote:
> What we really want is some form of API to extend/patch an existing jimage
> preserving everything else. Perhaps I should look into that. Would that be
> worth doing?
I think avoiding the plugin pipeline in creating a linkable image
On Tue, 19 Mar 2024 18:05:31 GMT, Mandy Chung wrote:
> Thanks for the details. I feel the pain in extending jlink for this work as
> the current jlink implementation is not easily understandable and has been
> yearning for rewrite in my perspective (looking forward to Project Leyden's
>
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
>>
> 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
> install might not come with the packaged modules (directory
27 matches
Mail list logo