I fully understand why authors of (truly excellent, in your case!) advanced
serviceability agents would see any feature that could affect their area of
interest as a problem, but you surely understand that our responsibility is
toward a far larger ecosystem. Even the ultimate restriction — which
Hi Ron,
I reviewed integrity JEPs once again along with this email thread and I
think there are several flaws in the proposal that need to be addressed
before implementation.
1. First, the JEP draws equality between an agent and an instrumenting
agent, which is not true. Instrumentation i
Because the discussion of this JEP has veered in many directions, let me
summarise where we are:
This JEP proposes to emit a suppressible warning when a JVM TI or Java agent is
loaded into a JVM sometime after startup through the Attach mechanism.
The warning helps make users aware that an agen
> On 18 May 2023, at 23:52, Kirk Pepperdine wrote:
>
>>
>> By “restricted” we mean “disallowed by default unless the application allows
>> it.” We try to use that terminology consistently. In this JEP we’re just
>> “preparing to restrict”, which means that unless explicitly allowed by the
>
> On May 18, 2023, at 2:55 PM, Ron Pressler wrote:
>
>
>> On 18 May 2023, at 21:45, Kirk Pepperdine wrote:
>>
>> Hi Ron,
>>
>> And in that JEP there is...
>>
>> "To attain our goal of integrity by default, we will gradually restrict
>> these APIs and close all loopholes in a series of up
> On 18 May 2023, at 21:45, Kirk Pepperdine wrote:
>
> Hi Ron,
>
> And in that JEP there is...
>
> "To attain our goal of integrity by default, we will gradually restrict these
> APIs and close all loopholes in a series of upcoming JEPs, ensuring that no
> library can assume superpowers with
Hi Ron,
And in that JEP there is...
"To attain our goal of integrity by default, we will gradually restrict these
APIs and close all loopholes in a series of upcoming JEPs, ensuring that no
library can assume superpowers without the application's consent. Libraries
that rely on these APIs shou
The explanation is given in the informational JEP:
https://openjdk.org/jeps/8305968
The problem is not any superpowered functionality, but superpowered
functionality that isn’t explicitly allowed by the application and used by
libraries without the application’s explicit consent. Both the -java
Hi Ron,
Thanks for the reply. The way I see this is that we have functionality that can
be accessed either via a dynamic attach pathway and a direct attach pathway.
What I’m trying to reconcile is how shutting down the dynamic attach pathway
helps with code integrity given that I can use the di
Let's actually see whether my reports are helpful or not, since you
ignored at least four out six. I'll focus on one at a time so that we
can exactly identify the consequences.
Scenario 1 (it's still in the thread below) are customers who CAN change
their command line. But they are inexperienc
Look, we have two goals:
1. Due to the reasons explained in the informational JEP, libraries must not be
allowed to grant themselves superpowers by means of injecting agents into their
host application.
2. We’d like to minimise the impact on honest-to-god serviceability tools that
actually *ha
You will be able to perform dynamic attach even without the flag (the flag is
*not* required for dynamic attach, only for using dynamic attach to load
agents). With the flag, your dynamic attach will be able load an agent into the
target VM.
BTW, LTS is something that’s governed by Oracle Sales
Hi All,
With this change, will I be able to perform a dynamic attach if I opt in using
the command line switch in JDK 25 (which I believe is the next LTS).
Kind regards,
Kirk
> On May 18, 2023, at 9:31 AM, Ron Pressler wrote:
>
> First, you will need to accept that no one is as invested in t
I have repeatedly suggested, on the original jdk-dev thread, that this
needs to be taken to a wider audience. Each time that request was
ignored. These email lists are niche, and are popuated by subscribers
who are interested in technical development of the JVM, which is
entirely the wrong audi
First, you will need to accept that no one is as invested in the user
experience of the Java ecosystem as a whole as much as OpenJDK’s maintainers,
and no one is as incentivised to work toward its continued success. If you
don’t believe it, you will still need to accept it axiomatically if you w
You asked for reports of common uses of dynamically loaded agents for
serviceability and difficulties setting a flag. I have provided several.
You have ignored most of the examples, and categorized the remainder as
"incorrect uses of Java" (by which I assume you mean incorrect uses of
JVMs), as
It is simply untenable to accommodate many incorrect uses of Java on top of the
correct ones, and, for example, allowing the dynamic loading of agents but
disallowing loading them at startup is an incorrect use of Java. The solution
to people using Java incorrectly is to educate them — which thi
That's a strange analysis, two out of the six examples of well known
real world applications, systems and platforms has that claim. And these
are well known. I'm not sure where most of your comments come from, but
let me assume this isn't just a blanket dismissal because you're the JEP
sponsor
> On 18 May 2023, at 14:27, Mike Hearn wrote:
>
> Right, for agent loading it probably doesn't matter. I think the reaction is
> to the general direction of travel. Panama also requires a command line flag,
> JNI may do so in future, maybe other features. The latter would cause any fat
> jar
Right, for agent loading it probably doesn't matter. I think the reaction
is to the general direction of travel. Panama also requires a command line
flag, JNI may do so in future, maybe other features. The latter would cause
any fat jar app that does self-extraction of native code to break. That's
Just to be clear, the abilities of executable JARs have not been limited in
recent years any more than they had been before. When JEP 261 added the
--add-exports and --add-opens options and disabled self-attach it also added
the Add-Opens, Add-Exports, and Launcher-Agent-Class manifest attribute
The JDK *allows* bundling a JVM since 9 and makes it *possible* since about
15 (jpackage), but still doesn't make it *easy* like throwing a JAR around
was easy. Although you discuss market demand here, the market isn't really
united on what it wants in this case.
Eliminating deployment complexity
> On 17 May 2023, at 23:01, Gregg Wonderly wrote:
>
> Again, the supposition here, is that somehow anyone who once built an
> application into a jar file that is in use today, can somehow cause a release
> of a new version of the JDK that appears in a user’s environment, to
> correlate with
> On May 17, 2023, at 4:33 PM, Ron Pressler wrote:
>
> But keep in mind that since Java has shifted away from the JRE model,
> self-contained Java applications are encouraged to use jlink to embed their
> own runtime and pick their arbitrary command-line options rather than rely on
> execut
> On 17 May 2023, at 20:34, Gregg Wonderly wrote:
>
> The first thrust of Java deployment was Applets which used no “command line”
> and automatically deployed and “secured” the Java environment. Next was the
> automatic recognition of .jar files on the Windows environment (file type
> mapp
> On May 16, 2023, at 12:22 PM, Ron Pressler wrote:
>
> At the core of your arguments is the claim — that we’ve heard told
> second-hand but rarely if ever reported first-hand — that the inability to
> control the command line is common. This claim is very important because its
> implicatio
> On May 15, 2023, at 8:56 AM, Ron Pressler wrote:
>
>>
>> The issue is that release-specific code may need to use deep reflection to
>> fix bugs or compensate for limitations in a specific set of JDK releases.
>
> But mucking about with JDK internals requires the application’s approval as
> > For white-box testing of code in user modules, build tools and testing
frameworks should automatically emit --add-exports, --add-opens, and
--patch-module for the module under test, as appropriate (for example,
patching the module under test with the contents of the test module allows
the testi
> On 15 May 2023, at 23:24, Brice Dutheil wrote:
>
> Hi,
>
> I do share some concerns of the community, however many have voiced it with a
> better english that I could ever do. But I'd like to mention two things:
>
> 1. There is another usage that I think will be visibly impacted : in tests
I appreciate your feedback. But I still contend that there is little
understanding of all the doors that changes to the Java and problems with
changes to the platform have closed. I’ve invested a large part of my career
to the use of Java. But, because of numerous things, I can no longer get
At the core of your arguments is the claim — that we’ve heard told second-hand
but rarely if ever reported first-hand — that the inability to control the
command line is common. This claim is very important because its implications
go well beyond the relatively niche issue of dynamically loaded
Here I refer to anyone who is operating the JVM as a customer. Scenarios
where this JEP will (when moved from deprecation to fully applied)
onerously adversely impact customers include:
1. Most obviously, those customers who have running JVMs, decide they
want to add an observability agent, bu
Hi,
I do share some concerns of the community, however many have voiced it with
a better english that I could ever do. But I'd like to mention two things:
1. There is another usage that I think will be visibly impacted : in tests
it's often necessary to alter part of the system to stress some par
> On 14 May 2023, at 21:28, Alan Snyder wrote:
>
>
>> On May 14, 2023, at 6:07 PM, Ron Pressler wrote:
>>
>> You can continue using JNI, but the application on newer releases will need
>> to allow it. But the way to target multiple releases in a general and
>> elegant way is with multi-rel
> On May 14, 2023, at 6:07 PM, Ron Pressler wrote:
>
> You can continue using JNI, but the application on newer releases will need
> to allow it. But the way to target multiple releases in a general and elegant
> way is with multi-release JARs.
Multi-release JARs may be better than conditiona
> On 14 May 2023, at 19:45, Alan Snyder wrote:
>
> Interesting discussion.
>
> I’m more worried about JNI. Can you say anything about how you see JNI being
> restricted?
Probably in the exact same was as FFM, i.e. with the --enable-native-access
flag.
>
> I use JNI not only to access nati
Interesting discussion.
I’m more worried about JNI. Can you say anything about how you see JNI being
restricted?
I use JNI not only to access native services but also to work around bugs or
limitations in the JDK using its unrestricted reflection.
As a library developer, I want my library to wo
> On 12 May 2023, at 18:01, Kirk Pepperdine wrote:
>
> Hi Ron,
>
> I’m trying to work through some confusion and past 3 levels of discomfort.
> The confusion is, the JEP talks about code integrity and that agents (both
> directly and dynamically attached) have the ability to alter loaded cod
On 13/05/2023 00:42, Gregg G Wonderly wrote:
I find it petty that “we know best” or “it’s our way of the highway” becoming
a pretty common thing in the “evolution” of Java “by Oracle”. The open-JDK
community ultimately can end up quite distances from “Oracle Java”.
It seems there is an agend
On 5/12/2023 4:42 PM, Gregg G Wonderly wrote:
The removal of the security manager is a big deal. Jini, now River
has counted on mobile code, controlled by the security manager for
decades. Visibility of many of the uses has always been problematic
because of the benefits the speed of the platform
Sent from my iPhone
> On May 12, 2023, at 1:29 PM, Ron Pressler wrote:
>
> (Moving to the appropriate mailing lists for the discussion of this JEP)
….
> By physical necessity we sometimes inconvenience some users because users
> have contradictory requirements. What we’re trying to estimat
Hi Ron,
I’m trying to work through some confusion and past 3 levels of discomfort. The
confusion is, the JEP talks about code integrity and that agents (both directly
and dynamically attached) have the ability to alter loaded code. That the JEP
paints the capability in a “bad light” is judgment
(Moving to the appropriate mailing lists for the discussion of this JEP)
We want reports of common uses of dynamically loaded agents for serviceability
and difficulties setting a flag. Our judgment will sway if we learn that the
use of dynamically loaded agents for serviceability is very common
> On 10 May 2023, at 07:07, Volker Simonis wrote:
>
>
> I still wonder why this JEP has scope "SE"? During the discussion
> about the draft (which was initially about "disallowing by default")
> it was mentioned that once dynamic loading will be disabled by
> default, this will be mandated in
On Mon, May 8, 2023 at 9:17 PM Mark Reinhold wrote:
>
> https://openjdk.org/jeps/451
>
> Summary: Issue warnings when agents are loaded dynamically into a
> running JVM. These warnings aim to prepare users for a future release
> which disallows the dynamic loading of agents by default in ord
https://openjdk.org/jeps/451
Summary: Issue warnings when agents are loaded dynamically into a
running JVM. These warnings aim to prepare users for a future release
which disallows the dynamic loading of agents by default in order to
improve integrity by default. Serviceability tools that
46 matches
Mail list logo
