New candidate JEP: 451: Prepare to Disallow the Dynamic Loading of Agents

[Alex Buckley]

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 platforms involved.  Racing
> platforms, trading platforms and even network cross routing have been
> happening.  But the announcement of the drop of the security manager
> pretty much shut the whole platform down.  A lot of time was
> committed, in the community, to create a new implementation that
> greatly improved the really poor use of locks and contested access
> scopes.  But once again, we see the “we know best” thing looming
> around such changes.

You're saying in essence that Oracle and the OpenJDK Community can never 
remove anything from the Java Platform, because removing *anything* is 
going to be a big deal to *someone*. But it is not realistic to expect 
every component of the Java Platform to be maintained forever -- I hope 
you can agree with the principle of this statement.

In the specific case of the Security Manager, the programming model it 
engendered was sorely lacking in scalability (i.e., hard to compose 
permissions from different components) and the result was low uptake 
after *25 years* in the field. (Not zero update! Just low.)

Probably more than anyone else, *we* are disappointed that the Security 
Manager "experiment" to bring principle-of-least-privilege to a popular 
language didn't work out. Countless JavaOne sessions, years of 
maintenance on java.lang.SecurityManager, endless code reviews on the 
JDK's permission checks -- none of it was effective because programming 
under the Security Manager was too hard and the vast majority of Java 
applications were happy to run with the default: Security Manager 
disabled. (Java has turned picking questionable defaults into an art form.)

> I think it would be very beneficial for Oracle to make some publicly
> visible statements about where it’s taking Java so that the
> community, could understand if there is an incongruity of that path
> and what uses the community has planned.
There are two world-class documents which describe the path Java is on:

1. https://openjdk.org/projects/leyden/notes/02-shift-and-constrain

"We can often improve a program’s startup time, warmup time, and 
footprint by shifting some of its computation temporally, either forward 
to a point later in run time (e.g., via lazy initialization) or backward 
to a point earlier than run time (e.g., via ahead-of-time compilation). 
We can further improve performance by constraining some of the 
computation related to Java’s dynamic features (e.g., class loading, 
class redefinition, and reflection), which enables better code analysis 
and thus even more optimization."

2. https://openjdk.org/jeps/8305968#Beyond-Deep-Reflection

"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 should spend 
the time remaining until they are restricted to prepare their users for 
any necessary changes."

We try to "join the dots" so that everyone can see how all the roadmaps 
are headed in the same direction, but we can do better, and we'll try 
harder to explain the "big picture" in all media -- on OpenJDK lists, in 
podcasts, on blogs, in videos, at events, in books, everywhere people 
get their Java.

Alex