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
