JEP 411, removal of finalizers, a path forward.
Alan.Bateman at oracle.com
Sun Aug 1 18:48:37 UTC 2021
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.
More information about the jdk-dev