nikhiln64 opened a new pull request, #6809: URL: https://github.com/apache/incubator-kie-drools/pull/6809
**Issue**: * https://github.com/apache/incubator-kie-drools/issues/6758 **Summary** Parallel capability is per-class, not inherited: `ProjectClassLoader` calls `registerAsParallelCapable()`, but the JVM checks the loader's **concrete runtime class** (and its whole superclass chain), so the concrete loaders never benefited - `getClassLoadingLock` fell back to locking the loader instance, serializing every class load through one monitor. Registered all five concrete classes: `DynamicProjectClassLoader`, `IBMDynamicClassLoader`, `StaticProjectClassLoader`, `IBMStaticClassLoader`, and `DummyInternalTypesClassLoader` (the dynamic `DefaultInternalTypesClassLoader` already had it). Thread-safety audit of what parallel loading newly exposes: the `defineType`/`defineClass`/`undefineClass` paths are already `synchronized`, and the `loadedClasses`/`nonExistingClasses` caches are `ConcurrentHashMap`s - the base class was designed for this; the subclasses just never opted in. **Testing** New tests in both wiring modules use a probe subclass: `registerAsParallelCapable()` returns `false` when any ancestor class is not itself registered, so the assertion is deterministic (no timing games) and goes red if a registration is ever removed - verified red against the unfixed loaders, green with the fix. Full `drools-wiring-dynamic` + `drools-wiring-static` test suites pass on JDK 17. Developed with AI assistance (Claude Code), reviewed and driven by a human. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
