Querstion about ForkJoinPool / SecurityManager interoperability

Patrick Reinhart patrick at reini.net
Thu Dec 13 12:36:47 UTC 2018

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

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

"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 

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


More information about the core-libs-dev mailing list