Re:Point by point (Score 2, Informative)

Classloaders are implemented the right way. So don't change this (The exception messages could be improved though).

Ack. The classloader architecture is one of the most poorly designed and inconsistently implemented parts of Java. The problem is that almost no one has to delve that deep into the doo-doo to get things done.

However, if you're unlucky enough to be building an enterprise server architecture that requires separate classloaders (to avoid the JAR-version-hell of the classpath) get ready for fun:

1. Half of the APIs in Java don't correctly use classloaders when they should. For example, when initializing the security API, you can't pass in a classloader - Java assumes that you will be using the standard classpath. WRONG!
2. Statics allocated in classes are NOT garbage collected when the classloader is destroyed. So, if you use a classloader to manage your resources and allow a graceful stop and restart, all of your strings, objects, what have you will never get GCd. UNBELIEVABLY WRONG!
3. The list goes on and on...

As I said, the only reason that people believe the classloader API isn't broken is that they probably haven't had to use it. It needs serious help, above and beyond the ridiculously pervasive classpath issues.