[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: Disallowing the dynamic loading of agents by default
From: Gregg G Wonderly <greggwon () cox ! net>
Date: 2023-03-25 19:56:50
Message-ID: 39D27A60-7914-4109-A19E-96AB5608A4F5 () cox ! net
[Download RAW message or body]
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) of what \
people actually do with Java.
Sent from my iPhone
> On Mar 25, 2023, at 5:29 AM, Bernd <ecki@zusammenkunft.net> wrote:
>
>
> Gregg i have to disagree, not only is Java one of the most stable platform out \
> there but also the „Enterprise Desktop" couldn't care less about the default of \
> this switch.
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> Von: serviceability-dev <serviceability-dev-retn@openjdk.org> im Auftrag von Gregg \
> Wonderly <greggwon@cox.net>
> Gesendet: Freitag, März 24, 2023 11:42 PM
> An: Andrew Dinn <adinn@redhat.com>
> Cc: Ron Pressler <ron.pressler@oracle.com>; jigsaw-dev@openjdk.org \
> <jigsaw-dev@openjdk.org>; serviceability-dev@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 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've watch any favoritism towards java on the desktop or as a \
> general solution programing language wane, because it's undependable as a platform. \
> You never no when something will break as these "stability" changes occur. People \
> who use software systems are in large part not programers or language/platform \
> experts. The in ability of Oracle and many others to understand how detrimental \
> this behavior has been is just mind blowing.
> People like myself end up looking like whining babies because we come back every \
> once in a while to see if there is something useful happening in Java development \
> that might finally stabilize the platform on the desktop and other business \
> environments and low and behold write-once-run-anywhere is found to still be \
> unimplemented and basically non appreciated. It's just a sad, sad thing to see \
> happening.
> Sun first did this with Java 1.2. The Community beat up on Sun severely and \
> everything quieted down for a while. Then we had the JDK 1.5 release where my much \
> mentioned volatile reachability optimizations broke software all over the place.
> This is not happening in any other language I am aware of. The people at Sun who \
> were causing all the problems seemed to have gone on to Oracle and there is just a \
> core group of people who just do not understand how horrible Java looks these days \
> because of how much basic functionality got completely broken when a new version of \
> Java showed up on general purpose computing and working software just stopped \
> working…
> Gregg Wonderly
>
> > On Mar 24, 2023, at 12:21 PM, Andrew Dinn <adinn@redhat.com> 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 requirements for adaptation of \
> > Jigsaw to incorporate the needs of agents.
> > As an aside, I'll note that a thorough review was necessary /even/ in my case, \
> > despite the fact that I was an active party, because the discussion occurred, and \
> > corresponding decisions were made, quite some time ago. I mention this because it \
> > may explain the air of surprise and the desire to reiterate some of the original \
> > debate on the part of some respondents in this thread, who perhaps were not \
> > party, or only tangentially party, to the discussion.
> > That also suggests that there may be a lot users who are not aware that the \
> > -XX:+EnableDynamicAgentLoading switch exists or do not really understand why it \
> > exists i.e. that there is a broad education issue at play here.
> > We do have some concerns about the JEP, specifically about the timing of its \
> > delivery. These are probably best addressed via the normal review process. In \
> > particular that will ensure the discussion happens in a more suitable and more \
> > widely subscribed forum than the Jigsaw list. However, I will briefly mention our \
> > concerns in this reply. Before that let me start with a few disclaimers:
> > - We acknowledge that there is little to be gained from re-iterating arguments \
> > made in the previous discussion (although that does not imply the JEP review \
> > would not benefit from new arguments, especially from those who were not involved \
> > in that discussion)
> > - We recognize that the purpose of the -XX:+EnableDynamicAgentLoading switch is \
> > to offer a platform integrity guarantee and that this change of the default \
> > reflects a desire to prioritise integrity over the flexibility that agents \
> > provide
> > - We recognize that the proposal is only proposing to flip a configuration \
> > default rather than detract from (or modify) available functionality
> > - We recognize that changing this default will still allow (*most*) users to \
> > configure the behaviour they desire
> > - We recognize that this advance notice has been given precisely to ensure that \
> > anyone wishing to deploy on jdk21 an app that relies on use of agents has time to \
> > plan appropriate configuration for their deployment
> > - We recognize that this change of default is not being proposed for backport and \
> > hence that it will largely only affect the relatively small number of users who \
> > are currently developing for jdk21+
> > So, given that as a base for our comments where is the beef?
> >
> > - Our main concern is, predictably, timing. Clearly, this is a future, potential \
> > problem rather than a present problem - no one can be deploying on jdk21 yet and \
> > most developers who are currently preparing an app for deployment on jdk21+ will \
> > likely encounter the effect of this change before actual deployment and be in a \
> > position to remedy it. The concern is that advertising a change like this and \
> > getting users prepared to respond to it has always been difficult to achieve. In \
> > particular we expect a long tail of support problems from users who are trying to \
> > upgrade deployments from earlier releases to jdk21. So, while it is nice to have \
> > such early notice of the proposal we plan to review its likely impact on our \
> > users and how much time we need to prepare ourselves and our users to negotiate \
> > this change in behaviour. Any evidence we obtain to suggest a delay in targeting \
> > is appropriate will be brought to the JEP review.
> > - A second, related concern is that flipping the default for this configuration \
> > in an LTS release as the first exposure to it for most people is more likely to \
> > derail deployment plans for users than if the default were flipped in a non-LTS \
> > release. If this change were deferred to jdk22 then that would give those \
> > planning deployment on (or upgrade to) jdk25 and also those planning to upgrade \
> > from jdk17 to jdk21 more time to discover and respond to the change.
> > - A third concern, already pointed out by Volker, is that some users may run \
> > their Java apps via launcher apps or scripts that mask access to the Java command \
> > line. For such users the change of default may mean that they lose the option to \
> > deploy dynamic agents for important ancillary tasks such as observability. We are \
> > not clear how many of our users this affects but we will be looking into this and \
> > hope to bring feedback to the JEP review. Obviously, this problem can be \
> > remedied relatively easily by the supplier of the launcher enabling agent use or \
> > providing a suitable control switch. Our concern is not with how to solve this \
> > problem rather how the involvement of two parties, supplier and end user, might \
> > imply a need for the JEP to be targeted to a later release.
> > regards,
> >
> >
> > Andrew Dinn
> > -----------
> > Red Hat Distinguished Engineer
> > Red Hat UK Ltd
> > Registered in England and Wales under Company Registration No. 03798903
> > Directors: Michael Cunningham, Michael ("Mike") O'Neill
> >
>
[Attachment #3 (text/html)]
<html><head><meta http-equiv="content-type" content="text/html; \
charset=utf-8"></head><body dir="auto">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) of what people actually do with Java.<br><br><div dir="ltr">Sent \
from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On Mar 25, 2023, at \
5:29 AM, Bernd <ecki@zusammenkunft.net> \
wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div \
dir="ltr"><div style="">
</div><div style=""><div>
<div>Gregg i have to disagree, not only is Java one of the most stable platform \
out there but also the „Enterprise Desktop" couldn't care less about the default of \
this switch. </div><div dir="ltr"><br></div><div dir="ltr">Gruss</div><div \
dir="ltr">Bernd </div><div id="ms-outlook-mobile-signature"><div \
style="direction:ltr">-- </div><div \
style="direction:ltr">http://bernd.eckenfels.net</div></div> </div>
<div> </div><hr style="display:inline-block;width:98%" tabindex="-1"><div \
id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif"><b>Von:</b> \
serviceability-dev <serviceability-dev-retn@openjdk.org> im Auftrag von Gregg \
Wonderly <greggwon@cox.net><br><b>Gesendet:</b> Freitag, März 24, 2023 11:42 \
PM<br><b>An:</b> Andrew Dinn <adinn@redhat.com><br><b>Cc:</b> Ron Pressler \
<ron.pressler@oracle.com>; jigsaw-dev@openjdk.org \
<jigsaw-dev@openjdk.org>; serviceability-dev@openjdk.org \
<serviceability-dev@openjdk.org><br><b>Betreff:</b> Re: Disallowing the dynamic \
loading of agents by default<div> </div></font></div>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. \
<br> <br>Over the years, I've watch any favoritism towards java on the desktop or as \
a general solution programing language wane, because it's undependable as a platform. \
You never no when something will break as these "stability" changes occur. People \
who use software systems are in large part not programers or language/platform \
experts. The in ability of Oracle and many others to understand how detrimental this \
behavior has been is just mind blowing. <br>
<br>People like myself end up looking like whining babies because we come back every \
once in a while to see if there is something useful happening in Java development \
that might finally stabilize the platform on the desktop and other business \
environments and low and behold write-once-run-anywhere is found to still be \
unimplemented and basically non appreciated. It's just a sad, sad thing to see \
happening. <br>
<br>Sun first did this with Java 1.2. The Community beat up on Sun severely and \
everything quieted down for a while. Then we had the JDK 1.5 release where my much \
mentioned volatile reachability optimizations broke software all over the place. <br>
<br>This is not happening in any other language I am aware of. The people at Sun who \
were causing all the problems seemed to have gone on to Oracle and there is just a \
core group of people who just do not understand how horrible Java looks these days \
because of how much basic functionality got completely broken when a new version of \
Java showed up on general purpose computing and working software just stopped \
working… <br>
<br>Gregg Wonderly
<br>
<br>> On Mar 24, 2023, at 12:21 PM, Andrew Dinn <adinn@redhat.com> wrote:
<br>>
<br>> Hi Ron,
<br>>
<br>> 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. <br>>
<br>> As an aside, I'll note that a thorough review was necessary /even/ in my \
case, despite the fact that I was an active party, because the discussion occurred, \
and corresponding decisions were made, quite some time ago. I mention this because it \
may explain the air of surprise and the desire to reiterate some of the original \
debate on the part of some respondents in this thread, who perhaps were not party, or \
only tangentially party, to the discussion. <br>>
<br>> That also suggests that there may be a lot users who are not aware that the \
-XX:+EnableDynamicAgentLoading switch exists or do not really understand why it \
exists i.e. that there is a broad education issue at play here. <br>>
<br>> We do have some concerns about the JEP, specifically about the timing of its \
delivery. These are probably best addressed via the normal review process. In \
particular that will ensure the discussion happens in a more suitable and more widely \
subscribed forum than the Jigsaw list. However, I will briefly mention our concerns \
in this reply. Before that let me start with a few disclaimers: <br>>
<br>> - We acknowledge that there is little to be gained from re-iterating \
arguments made in the previous discussion (although that does not imply the JEP \
review would not benefit from new arguments, especially from those who were not \
involved in that discussion) <br>>
<br>> - We recognize that the purpose of the -XX:+EnableDynamicAgentLoading \
switch is to offer a platform integrity guarantee and that this change of the default \
reflects a desire to prioritise integrity over the flexibility that agents provide \
<br>> <br>> - We recognize that the proposal is only proposing to flip a \
configuration default rather than detract from (or modify) available functionality \
<br>> <br>> - We recognize that changing this default will still allow \
(*most*) users to configure the behaviour they desire <br>>
<br>> - We recognize that this advance notice has been given precisely to ensure \
that anyone wishing to deploy on jdk21 an app that relies on use of agents has time \
to plan appropriate configuration for their deployment <br>>
<br>> - We recognize that this change of default is not being proposed for \
backport and hence that it will largely only affect the relatively small number of \
users who are currently developing for jdk21+ <br>>
<br>> So, given that as a base for our comments where is the beef?
<br>>
<br>> - Our main concern is, predictably, timing. Clearly, this is a future, \
potential problem rather than a present problem - no one can be deploying on jdk21 \
yet and most developers who are currently preparing an app for deployment on jdk21+ \
will likely encounter the effect of this change before actual deployment and be in a \
position to remedy it. The concern is that advertising a change like this and getting \
users prepared to respond to it has always been difficult to achieve. In particular \
we expect a long tail of support problems from users who are trying to upgrade \
deployments from earlier releases to jdk21. <br>> So, while it is nice to have \
such early notice of the proposal we plan to review its likely impact on our users \
and how much time we need to prepare ourselves and our users to negotiate this change \
in behaviour. Any evidence we obtain to suggest a delay in targeting is appropriate \
will be brought to the JEP review. <br>>
<br>> - A second, related concern is that flipping the default for this \
configuration in an LTS release as the first exposure to it for most people is more \
likely to derail deployment plans for users than if the default were flipped in a \
non-LTS release. If this change were deferred to jdk22 then that would give those \
planning deployment on (or upgrade to) jdk25 and also those planning to upgrade from \
jdk17 to jdk21 more time to discover and respond to the change. <br>>
<br>> - A third concern, already pointed out by Volker, is that some users may \
run their Java apps via launcher apps or scripts that mask access to the Java command \
line. For such users the change of default may mean that they lose the option to \
deploy dynamic agents for important ancillary tasks such as observability. We are not \
clear how many of our users this affects but we will be looking into this and hope to \
bring feedback to the JEP review. <br>> Obviously, this problem can be remedied \
relatively easily by the supplier of the launcher enabling agent use or providing a \
suitable control switch. Our concern is not with how to solve this problem rather how \
the involvement of two parties, supplier and end user, might imply a need for the JEP \
to be targeted to a later release. <br>>
<br>> regards,
<br>>
<br>>
<br>> Andrew Dinn
<br>> -----------
<br>> Red Hat Distinguished Engineer
<br>> Red Hat UK Ltd
<br>> Registered in England and Wales under Company Registration No. 03798903
<br>> Directors: Michael Cunningham, Michael ("Mike") O'Neill
<br>>
<br>
<br></div></div>
</div></blockquote></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic