Most uses cases for custom classloaders address situations where a dynamism is required that the built-in classloaders can't provide, because they stay around for the lifetime of the JVM. That can be too long a time to wait for changes, and restarting the JVM may not be desirable.
Here's a little writeup I once did on application plugins - it uses classloaders to put security measures in place.
Another use case to replace classes at runtime with updated versions; OSGi is the high-end solution to this, and it relies on classloaders.
Another use case is the reloading of web apps in servlet containers (and app servers in general). Classloaders are used to separate the various web apps from one another (thus making sure that each web app has its own set of static variables, for example), but also make it possible to reload web apps without having to restart the JVM - thus without impacting the other web apps.
Having said that, it's perfectly possible to be a Java programmer for 10 years and never having to use a custom classloader - it's a very specialized solution to some not very common problems.
posted 5 years ago
Ivan Jozsef Balazs wrote:I experienced e.g. that the Bouncy Castle cryptography provider did not work if put into the very applications. It had to be put into a central place as a JVM-level resource.
That's an example of using classloaders for security restrictions - classes loaded by different classloaders can have different permissions (that's what my little plugin example shows). Even the most simple scenario of a desktop app has at least 3 different classloaders; the bootstrap classloader, the extension classloader, and the application classloader. While you generally need not be concerned with them, hooking into the security infrastructure (like by adding a different JCE provider) can't be done at the application classloader level.