WeldResourceLoader is used to determine a class loader to load classes with for further processing. The code now tries to grab the TCCL and work primarily with that, using WeldResourceLoader.class.getClassLoader() as a fallback should TCCL be null. Now, if in SE and with bean discovery enabled, we by default use ForkJoinPool. JDK 8 and 9+ both have different results if you invoke Thread.currentThread().getContextClassLoader() and operate on a thread from ForkJoinPool. See this JDK issue for more info. In short, since JDK 9+, any thread from this pool has hard-set system CL as it's TCCL whereas in JDK 8 this was inherited from parent thread. Alas, system CL cannot load the classes we need, hence we get errors. The solution would be to implement a fallback behaviour, trying TCCL first, then using CL which loaded WeldResourceLoader. Alternatively, we can think of setting setting TCCL to null, just like it's done in WFLY. |