On Fri, 22 Nov 2024 17:04:38 GMT, Severin Gehwolf wrote:
>> Please review this simple patch which adds a new external system property
>> `jdk.patched` when the runtime has been patched with the `--patch-module`
>> switch. This is useful for two reasons: 1) it allows one to determine at
>> run-
On Tue, 26 Nov 2024 18:14:29 GMT, Mandy Chung wrote:
> For jlink to detect if the current runtime is patched, have you tried
> `ModuleBootstrap.patcher().hasPatches()` which I think it's an alternative to
> avoid introducing this system property.
I'm considering to drop this PR and filter reso
On Fri, 22 Nov 2024 17:04:38 GMT, Severin Gehwolf wrote:
>> Please review this simple patch which adds a new external system property
>> `jdk.patched` when the runtime has been patched with the `--patch-module`
>> switch. This is useful for two reasons: 1) it allows one to determine at
>> run-
On Fri, 22 Nov 2024 17:04:38 GMT, Severin Gehwolf wrote:
>> Please review this simple patch which adds a new external system property
>> `jdk.patched` when the runtime has been patched with the `--patch-module`
>> switch. This is useful for two reasons: 1) it allows one to determine at
>> run-
On Fri, 22 Nov 2024 17:04:38 GMT, Severin Gehwolf wrote:
>> Please review this simple patch which adds a new external system property
>> `jdk.patched` when the runtime has been patched with the `--patch-module`
>> switch. This is useful for two reasons: 1) it allows one to determine at
>> run-
On Mon, 25 Nov 2024 11:01:10 GMT, Alan Bateman wrote:
> I could use some background, the property itself seems like a hack, and those
> tend to live too long. What state that might be patched is used to create the
> new image?
With JEP 493, one can link (run `jlink`) without `jmods` folder. In
On Fri, 22 Nov 2024 17:31:39 GMT, Roger Riggs wrote:
> I could use some background, the property itself seems like a hack, and those
> tend to live too long. What state that might be patched is used to create the
> new image? How does jlink know that a configuration has been modified and
> ref
On Fri, 22 Nov 2024 17:04:38 GMT, Severin Gehwolf wrote:
>> Please review this simple patch which adds a new external system property
>> `jdk.patched` when the runtime has been patched with the `--patch-module`
>> switch. This is useful for two reasons: 1) it allows one to determine at
>> run-
> Please review this simple patch which adds a new external system property
> `jdk.patched` when the runtime has been patched with the `--patch-module`
> switch. This is useful for two reasons: 1) it allows one to determine at
> run-time whether or not `--patch-module` has been used (by querying
On Thu, 21 Nov 2024 10:29:32 GMT, Severin Gehwolf wrote:
> While at it, should there be additional guards to prevent applications from
> changing the value of this system property by doing
> `System.setProperty("jdk.patched")` at runtime?
The updated patch has a test for this. In a nutshell an
> Please review this simple patch which adds a new external system property
> `jdk.patched` when the runtime has been patched with the `--patch-module`
> switch. This is useful for two reasons: 1) it allows one to determine at
> run-time whether or not `--patch-module` has been used (by querying
On Wed, 20 Nov 2024 14:26:27 GMT, Severin Gehwolf wrote:
> Please review this simple patch which adds a new external system property
> `jdk.patched` when the runtime has been patched with the `--patch-module`
> switch. This is useful for two reasons: 1) it allows one to determine at
> run-time
On Thu, 21 Nov 2024 07:46:46 GMT, Alan Bateman wrote:
> > Having now looked at #22037 which is what motivated this change, I now have
> > a more basic question.
> > The `--patch-module` option is an option for the `java` command. The code
> > changes in this current PR is proposing to set a sys
On Thu, 21 Nov 2024 05:24:26 GMT, Jaikiran Pai wrote:
> in addition, should we explicitly set this system property to false (or
> remove the system property) when --patch-module isn't used? I think that
> would then prevent applications from passing -Djdk.patched=true when the
> runtime hasn't
On Wed, 20 Nov 2024 14:26:27 GMT, Severin Gehwolf wrote:
> Please review this simple patch which adds a new external system property
> `jdk.patched` when the runtime has been patched with the `--patch-module`
> switch. This is useful for two reasons: 1) it allows one to determine at
> run-time
On Wed, 20 Nov 2024 14:26:27 GMT, Severin Gehwolf wrote:
> Please review this simple patch which adds a new external system property
> `jdk.patched` when the runtime has been patched with the `--patch-module`
> switch. This is useful for two reasons: 1) it allows one to determine at
> run-time
On Wed, 20 Nov 2024 18:16:22 GMT, Severin Gehwolf wrote:
> Sorry about that. There weren't any major objections, so I moved forward as
> there was radio-silence for a while:
That's okay, my comment wasn't aimed at you, it was instead just observing that
there wasn't much feedback.
---
On Wed, 20 Nov 2024 17:45:18 GMT, Alan Bateman wrote:
> I had hoped you would get more feedback on the proposal.
Sorry about that. There weren't any major objections, so I moved forward as
there was radio-silence for a while:
https://mail.openjdk.org/pipermail/core-libs-dev/2024-November/134623
On Wed, 20 Nov 2024 14:26:27 GMT, Severin Gehwolf wrote:
> Please review this simple patch which adds a new external system property
> `jdk.patched` when the runtime has been patched with the `--patch-module`
> switch. This is useful for two reasons: 1) it allows one to determine at
> run-time
Please review this simple patch which adds a new external system property
`jdk.patched` when the runtime has been patched with the `--patch-module`
switch. This is useful for two reasons: 1) it allows one to determine at
runtime whether or not `--patch-module` has been used (by querying the said
20 matches
Mail list logo
