I think while this discussion is an interesting one, and clearly one the
elicits strong opinions; I believe that the focus on the proposed change
on dynamic loading of agents has truly been lost therein, further
exchanges have little relevance to the topic of Java serviceability and
the issue a
Hi Gregg,
Thanks for your reply. I only have one small point to make.
On 28/03/2023 16:35, Gregg Wonderly wrote:
Again, the supposition is that somehow users of software systems are always
surrounded by version planning and management. . . .
No, actually, my supposition is that users of softw
> On 29 Mar 2023, at 01:29, Gregg G Wonderly wrote:
>
> This is exactly my point! Why would any one want to do something like this?
> This level of workaround and specialized deployment is the kind of breakage
> that I am referring to. I just don’t understand how this kind of rigging and
Why, well, you get more features, it's easier for the end user, and
not any harder for the developer. Those are pretty concrete reasons
why people would want to do it that way. I'd suggest trying Conveyor
out yourself before worrying about rigging or customization, because
straightforward Java apps
This is exactly my point! Why would any one want to do something like this?
This level of workaround and specialized deployment is the kind of breakage
that I am referring to. I just don’t understand how this kind of rigging and
customization can even start to feel right.
Gregg Wonderly
> O
Hi Gregg,
Distributing little apps as JARs indeed doesn't work well anymore out
of the box, but it doesn't have to be the end of the line for them.
I've spent a couple of years writing a tool designed explicitly to
solve all these problems [1]. You give Conveyor your JARs (or a
Maven/Gradle build)
: Andrew Dinn Cc: Ron Pressler ; jigsaw-...@openjdk.org ; serviceability-dev@openjdk.org Betreff: Re: [External] : Re: Disallowing the dynamic loading of agents by default
> On Mar 28, 2023, at 4:13 AM, Andrew Dinn wrote:
>
> Greeg,
>
> I won't respond point by point to your
> On Mar 28, 2023, at 4:13 AM, Andrew Dinn wrote:
>
> Greeg,
>
> I won't respond point by point to your comments as I cannot see any great
> value in doing so. I really only want to make one general comment about your
> account below, which is that you appear to me to be relaying your own
Applications can now control the Java version available to them (and this is
something we’ll keep improving), and the JRE, the centralised Java environment
installed on user machines, has not existed for some time.
Strong encapsulation (which this change is part of) has made compatibility
better
Greeg,
I won't respond point by point to your comments as I cannot see any
great value in doing so. I really only want to make one general comment
about your account below, which is that you appear to me to be relaying
your own experience as a desktop Java user and universalising it to all
us
On Mar 27, 2023, at 11:30 AM, Andrew Dinn wrote:
> If this is pushed in jdk21 then anyone currently developing or upgrading an
> app to target jdk21 will only have been able to test on jdk17-jdk20 where
> they will not encounter the issue. So, his nly leaves them a small window to
> detect that
Hi Ron,
Thanks for the reply, I believe we have established a lot of common
ground here. I'll try to clarify a couple of the things you found
difficult to follow.
On 27/03/2023 11:32, Ron Pressler wrote:
- A second, related concern is that flipping the default for this
configuration in a
Sorry, let me correct some of my mangled grammar
On 27/03/2023 17:06, Andrew Dinn wrote:
On 27/03/2023 13:37, Volker Simonis wrote:
The JEP itself is rather ambitious because I noticed that most of the
strong encapsulation JEPs lacked a substantial motivation section
(largely because they had
On 27/03/2023 13:37, Volker Simonis wrote:
The JEP itself is rather ambitious because I noticed that most of the strong
encapsulation JEPs lacked a substantial motivation section (largely because
they had been written before that became the norm) and so strong encapsulation
has not been motiva
On Mon, Mar 27, 2023 at 12:32 PM Ron Pressler wrote:
>
> Hi Andrew!
>
> > On 24 Mar 2023, at 17:21, Andrew Dinn wrote:
> >
> > Hi Ron,
> >
> > Thank you for providing a heads up on the proposed JEP. The Red Hat Java
> > team have been discussing this proposal. We have reviewed the original
> >
> On 25 Mar 2023, at 19:56, Gregg G Wonderly wrote:
>
> I understand you may have personal experiences with how you use Java. In my
> experience and others, Java has constantly had fundamental breakage in
> various details due to lack of understanding, on the platform development
> team(s)
Hi Andrew!
> On 24 Mar 2023, at 17:21, Andrew Dinn wrote:
>
> Hi Ron,
>
> Thank you for providing a heads up on the proposed JEP. The Red Hat Java team
> have been discussing this proposal. We have reviewed the original discussion
> and also the surrounding debate which established requiremen
p://bernd.eckenfels.net
>
> Von: serviceability-dev im Auftrag von
> Gregg Wonderly
> Gesendet: Freitag, März 24, 2023 11:42 PM
> An: Andrew Dinn
> Cc: Ron Pressler ; jigsaw-...@openjdk.org
> ; serviceability-dev@openjdk.org
>
> Betreff: Re: Disallowing the dynamic lo
Wonderly Gesendet: Freitag, März 24, 2023 11:42 PMAn: Andrew Dinn Cc: Ron Pressler ; jigsaw-...@openjdk.org ; serviceability-dev@openjdk.org Betreff: Re: Disallowing the dynamic loading of agents by default Lot’s of people use Java in places where there is no “release” cycle of Java version in control
Lot’s of people use Java in places where there is no “release” cycle of Java
version in control of the users. These are “corporate users” in most cases and
they have Java applications that they are using which will just “stop working”
when a new version of Java is installed.
Over the years, I’
After all, we do know that Oracle in fact knows about every single Java
application, where it runs, where it’s deployed and what the future plans are
for the same. Otherwise, how else could they know what changes need to be made
in the platform, right?
Gregg Wonderly
> On Mar 20, 2023, at 5:1
Hi Ron,
Thank you for providing a heads up on the proposed JEP. The Red Hat Java
team have been discussing this proposal. We have reviewed the original
discussion and also the surrounding debate which established
requirements for adaptation of Jigsaw to incorporate the needs of agents.
As an
Hi Volker.
JEP 261 states: "The dynamic loading of JVM TI agents will be disabled by
default in a future release. To prepare for that change we recommend that
applications that allow dynamic agents start using the option
-XX:+EnableDynamicAgentLoading to enable that loading explicitly." The pur
> On 20 Mar 2023, at 17:53, Ron Pressler wrote:
>
> While the JEP will reiterate the relevant considerations (and no one denies
> that dynamically loaded agents are not useful)
Sorry, no one denies that dynamically loaded agents *are* useful :)
Hi Kirk.
While the JEP will reiterate the relevant considerations (and no one denies
that dynamically loaded agents are not useful) that led to this change being
announced some years ago, the purpose of my email was to announce it will
finally take effect in JDK 21. All the discussions at time,
Hi Ron,
> On Mar 20, 2023, at 3:10 AM, Ron Pressler wrote:
>
> Hi.
>
> The majority of serviceability tools don’t require dynamically loading an
> agent, and the majority of applications never load an agent dynamically.
While I wouldn’t be surprised that the majority don’t load agents dynami
Hi Ron,
I'm still missing convincing technical arguments for disallowing
dynamic loading of agents.
If the argument is security then I can only agree with previous
answers in that an attacker needs local access with the same
credentials like the attacked JVM. But once he has that, all bets are
of
AMAn: Ron Pressler Cc: Andrei Pangin ; jigsaw-...@openjdk.org ; serviceability-dev@openjdk.org Betreff: Re: [External] : Re: Disallowing the dynamic loading of agents by default Hi,On Mon, Mar 20, 2023 at 11:11 AM Ron Pressler <ron.press...@oracle.com> wrote:
Hi.
The majority of servicea
Hi,
On Mon, Mar 20, 2023 at 11:11 AM Ron Pressler
wrote:
> Hi.
>
> The majority of serviceability tools don’t require dynamically loading an
> agent, and the majority of applications never load an agent dynamically.
>
The majority of the JDK built-in tools, I would say. What about eg. the JMC
a
Hi.
The majority of serviceability tools don’t require dynamically loading an
agent, and the majority of applications never load an agent dynamically.
True, there are some tools that will be affected, which is why the decision was
to introduce the flag in JDK 9 and to announce this change, but
Hi all,
Serviceability has been one of the biggest Java strengths, but the proposed
change is going to have a large negative impact on it.
Disallowing dynamic agents by default means it will no longer be possible
to attach a profiler to a running app in runtime. JFR cannot close this gap
due to l
I need to retrace this thread to gain more context but my initial thoughts were
to all of the tools and techniques that I use and how vulnerable they are to
this change vs. what the motivation is for this change. My initial assessment
is that this is going to heavily impact visibility and wi
On 19/03/2023 02:51, Yasumasa Suenaga wrote:
:
Can we change flag type of EnableDynamicAgentLoading to `manageable`
from `product`? If so, we can use JVMTI agent without rebooting system
when we encountered some troubles in production system.
If manageable then it could be enabled at run-tim
HI,
I haven't followed this topic, but I think dynamic loading mechanism of JVMTI
agent is useful for debugging.
Can we change flag type of EnableDynamicAgentLoading to `manageable` from
`product`? If so, we can use JVMTI agent without rebooting system when we
encountered some troubles in pro
On 17/03/2023 14:11, Thomas Stüfe wrote:
:
Investigation shows that there seems to be a bug in attachListener.cpp
where we compare AttachOperation::name for "load", but it contains
"jcmd":
When using the Attach API, the VirtualMachine.loadAgentXXX methods map
to a "load" command. The Attach
> On 17 Mar 2023, at 14:11, Thomas Stüfe wrote:
>
> Thank you for the clarification.
>
> Oddly enough, -XX:-EnableDynamicAgentLoading seems to be broken. Tried head
> (fastdebug, release) and JDK17, even with this switch my sample library loads
> just fine:
>
> ```
> thomas@starfish$ ./imag
Thank you for the clarification.
Oddly enough, -XX:-EnableDynamicAgentLoading seems to be broken. Tried head
(fastdebug, release) and JDK17, even with this switch my sample library
loads just fine:
```
thomas@starfish$ ./images/jdk/bin/java -XX:-EnableDynamicAgentLoading
-XX:+PrintFlagsFinal -cp
On 17 Mar 2023, at 13:33, Thomas Stüfe
mailto:thomas.stu...@gmail.com>> wrote:
Hi Ron,
Will this affect attaching via jcmd?
The Attach mechanism will not be disabled by default, just the ability to load
agents via the Attach mechanism.
So the only jcmd command that will be affected is JVMTI.
Hi Ron,
Will this affect attaching via jcmd?
Thanks, Thomas
On Thu, Mar 16, 2023 at 7:48 PM Ron Pressler
wrote:
> Hi.
>
> In JDK 21 we intend to disallow the dynamic loading of agents by default.
> This
> will affect tools that use the Attach API to load an agent into a JVM some
> time
> after
Hi.
In JDK 21 we intend to disallow the dynamic loading of agents by default. This
will affect tools that use the Attach API to load an agent into a JVM some time
after the JVM has started [1]. There is no change to any of the mechanisms that
load an agent at JVM startup (-javaagent/-agentlib on t
40 matches
Mail list logo
