NOTE
Custom Java Class Loaders
How custom class loaders define classes, delegation, namespace isolation, and the operational risks of loader leaks.
This is a historical learning note and may contain outdated or incomplete understanding.
1. Why Custom Loaders Exist
Custom class loaders enable plugin systems, module/application isolation, dynamic loading, bytecode generation, and application-server/container architectures.
A typical implementation overrides findClass and lets the standard loadClass delegation mechanism decide whether a parent should load the class first.
2. Delegation
Parent-first delegation protects core platform classes and avoids defining duplicate versions unnecessarily. Some frameworks intentionally use child-first or selective rules for isolation, but those designs require careful package/API boundaries.
3. Class Identity
com.example.Foo loaded by loader A is a different runtime type from the same binary name loaded by loader B unless delegation makes them share the same definition.
This explains many plugin ClassCastException problems.
4. Loader Leaks
A class loader can be kept alive by threads, ThreadLocals, static registries, callbacks, caches, JNI references, or other objects rooted outside its intended lifecycle. Because its classes and metadata remain reachable with it, loader leaks can grow Metaspace/native usage.
Custom loading should therefore include an explicit unload/lifecycle strategy.