On 01/08/2021 15:28, Uwe Schindler wrote:
:
What I figured out: You intend to remove SecurityManager because it does not fit your latest ideas
how Java threads should behave. I know the main problem is not "SecurityManager is too complex
/ too slow / wrongly used /..." -- the main problem of some OpenJDK people around the Loom
project is that it won't work correctly with those new type of threads. You are now always arguing
against use cases of SecurityManager for the purpose of secuirty because you just want to hide that
the new "light" threads (aka fibers) in project Loom are incompatible to the stack-based
access control provided by AccessController and SecurityManager. So the only canard is Project Loom
- sorry!
This isn't right, I don't know where you got that. The only connection
to threads is the unspecified capturing of an access control context at
Thread create time. Loom has been betting that it will be irrelevant and
eventually removed so doesn't capture it. For the interim it just
specifies that virtual threads have "no permissions".
:
- Allow to hook into the I/O system. Unfortunately the java.nio FileSystem API
is not enough: it does not cover java.io.File (why is this the case?) nor does
the FileSystem API allows to hook in everywhere. We figured out that for
example the new Panama interface to get a MemorySegment from a file path is not
calling any API in the Filesystem abstraction!
There are bootstrapping and compatibility issues, this isn't the right
place to go into all that.
We have seen this in Java 9 already: Suddenly the module system was weakened
shortly before release: because there was no replacement for sun.misc.Unsafe.
This isn't right either. Critical internal APIs, including
sun.misc.Unsafe, were never encapsulated. So no change to the
accessibility of Unsafe when relaxed strong encapsulated was introduced
in Java 9.
-Alan
