JEP 411, removal of finalizers, a path forward.

[Alan Bateman]

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