Querstion about ForkJoinPool / SecurityManager interoperability

[Patrick Reinhart]

Hi everybody,

I'm not sure if this mailing list the correct one, if not please give me 
a note where to place that question.

When trying to use the Weld SE with together with a SecurityManager and 
I got a exception thrown out of the ForkJoinWorkerThread:

java.lang.SecurityException: setContextClassLoader
	at 
java.base/java.util.concurrent.ForkJoinWorkerThread$InnocuousForkJoinWorkerThread.setContextClassLoader(ForkJoinWorkerThread.java:239)


I did some digging in the ForkJoinPool and there it states the possible 
reason:

"If no thread factory is supplied via a system property, then the common 
pool uses a factory that uses the system class loader as the thread 
context class loader. In addition, if a SecurityManager is present, then 
the common pool uses a factory supplying threads that have no 
Permissions enabled. Upon any error in establishing these settings, 
default parameters are used. It is possible to disable or limit the use 
of threads in the common pool by setting the parallelism property to 
zero, and/or using a factory that may return null. However doing so may 
cause unjoined tasks to never be executed."


Now the special case of using those special threads with no permission 
are only created when the ForkJoinPool is initialized with a security 
manager installed at this point of time. If the security manager will be 
installed later, it has not impact what so ever (this is my actual 
work-around the problem for now)

Even if the security manager is enabled before the initialize of the 
ForkJoinPool not all work is delegated to InnocuousForkJoinWorkerThread 
instances (sometimes it picks the main thread instead, that has not the 
restrictions, what I think should not be the case and is a potential 
security leak too)

Why is this done this way and the change of the context class loader or 
uncaught exception handler not checked by the actual security manager 
instead?


Can anybody enlighten me on this so I can file the correct bug at the 
correct place :-)

-Patrick