On Tue, 3 Dec 2024 14:42:37 GMT, Severin Gehwolf wrote:
>> Please review this fix to how patched modules are being handled when linking
>> from the run-time image. During review of
>> [JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed
>> out that module patching should b
On Tue, 3 Dec 2024 17:53:44 GMT, Alan Bateman wrote:
> > @AlanBateman OK with this too?
>
> ModuleBootstap is the place to initialize the module system and setup the
> boot layer. The ModuleBootstrap.patcher() method is there for its buddy
> SystemModuleFinders, it should not be public. So I s
On Tue, 3 Dec 2024 17:33:09 GMT, Severin Gehwolf wrote:
> @AlanBateman OK with this too?
ModuleBootstap is the place to initialize the module system and setup the boot
layer. The ModuleBootstrap.patcher() method is there for its buddy
SystemModuleFinders, it should not be public. So I suppose
On Tue, 3 Dec 2024 17:24:51 GMT, Mandy Chung wrote:
> LGTM
Thanks for the review, @mlchung!
-
PR Comment: https://git.openjdk.org/jdk/pull/22037#issuecomment-2515184653
On Tue, 3 Dec 2024 14:42:37 GMT, Severin Gehwolf wrote:
>> Please review this fix to how patched modules are being handled when linking
>> from the run-time image. During review of
>> [JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed
>> out that module patching should b
On Tue, 3 Dec 2024 14:42:37 GMT, Severin Gehwolf wrote:
>> Please review this fix to how patched modules are being handled when linking
>> from the run-time image. During review of
>> [JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed
>> out that module patching should b
On Mon, 2 Dec 2024 19:05:10 GMT, Mandy Chung wrote:
> > The long-term plan would be to not need this at all. If we were to use the
> > jrt FS throughout in JRTArchive I think module patches won't matter and
> > wouldn't populate to the resulting image and this could get removed. But
> > that w
> Please review this fix to how patched modules are being handled when linking
> from the run-time image. During review of
> [JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed out
> that module patching should be detected earlier and the link should get
> aborted in that
On Mon, 2 Dec 2024 18:33:31 GMT, Mandy Chung wrote:
>> Severin Gehwolf 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 15 additional
>> commits
On Mon, 2 Dec 2024 18:48:39 GMT, Mandy Chung wrote:
>> Severin Gehwolf 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 15 additional
>> commits
On Wed, 27 Nov 2024 20:05:58 GMT, Severin Gehwolf wrote:
> The long-term plan would be to not need this at all. If we were to use the
> jrt FS throughout in JRTArchive I think module patches won't matter and
> wouldn't populate to the resulting image and this could get removed. But that
> woul
On Wed, 27 Nov 2024 20:01:01 GMT, Severin Gehwolf wrote:
>> Please review this fix to how patched modules are being handled when linking
>> from the run-time image. During review of
>> [JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed
>> out that module patching should
On Wed, 27 Nov 2024 20:01:01 GMT, Severin Gehwolf wrote:
>> Please review this fix to how patched modules are being handled when linking
>> from the run-time image. During review of
>> [JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed
>> out that module patching should
> Please review this fix to how patched modules are being handled when linking
> from the run-time image. During review of
> [JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed out
> that module patching should be detected earlier and the link should get
> aborted in that
On Thu, 14 Nov 2024 16:11:13 GMT, Severin Gehwolf wrote:
>> Yes, I'm wondering if a JDK-specific (rather than standard) property could
>> be more widely useful as it would allow observability tools to know that the
>> JDK has been patched. It would be good to get wider input on this.
>
> @AlanB
On Tue, 12 Nov 2024 13:52:12 GMT, Severin Gehwolf wrote:
>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line
>> 128:
>>
>>> 126: \ --keep-packaged-modules is not supported
>>> 127: err.runtime.link.modified.file={0} has been modified
>>> 128: err.runtime.link.patched.
> Please review this fix to how patched modules are being handled when linking
> from the run-time image. During review of
> [JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed out
> that module patching should be detected earlier and the link should get
> aborted in that
On Tue, 12 Nov 2024 14:29:08 GMT, Alan Bateman wrote:
>>> Instead, I think we should look at adding a property such as jdk.patched
>>
>> You mean a new standard property - observable with
>> `System.getProperty("jdk.patched")` as well - which would also show up with
>> `java -XshowSettings:pro
On Tue, 12 Nov 2024 14:34:45 GMT, Severin Gehwolf wrote:
>> Yes, I'm wondering if a JDK-specific (rather than standard) property could
>> be more widely useful as it would allow observability tools to know that the
>> JDK has been patched. It would be good to get wider input on this.
>
> OK, th
On Tue, 12 Nov 2024 13:51:17 GMT, Severin Gehwolf wrote:
>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 625:
>>
>>> 623: // Do not permit linking from run-time image when the
>>> current image
>>> 624: // is being patched
>>> 625:
On Tue, 12 Nov 2024 14:29:08 GMT, Alan Bateman wrote:
>>> Instead, I think we should look at adding a property such as jdk.patched
>>
>> You mean a new standard property - observable with
>> `System.getProperty("jdk.patched")` as well - which would also show up with
>> `java -XshowSettings:pro
On Tue, 12 Nov 2024 11:24:07 GMT, Alan Bateman wrote:
> Instead, I think we should look at adding a property such as jdk.patched
You mean a new standard property - observable with
`System.getProperty("jdk.patched")` as well - which would also show up with
`java -XshowSettings:properties`? Is t
On Tue, 12 Nov 2024 11:00:36 GMT, Severin Gehwolf wrote:
> Please review this fix to how patched modules are being handled when linking
> from the run-time image. During review of
> [JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed out
> that module patching should be d
Please review this fix to how patched modules are being handled when linking
from the run-time image. During review of
[JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed out
that module patching should be detected earlier and the link should get aborted
in that case.
Thi
24 matches
Mail list logo
