Hi Bryan, Bryan Atsatt wrote:
As long as there is some API support for disabling the loader, I'm fine with this approach.
Good.
However, this is not a feature I would ever advocate adding to java.lang.ClassLoader(!), since it really only makes sense in the context of a managed loader. In a managed environment with a true lifecycle, it is important to be able to *find* ongoing uses of a supposedly stopped module. The only way we've ever been able to do that is to ensure that any use of such a loader will cause an exception to be thrown. We have had great success with this model in finding code that does not participate correctly in the container lifecycle. The most common case is threads that aren't stopped when they should be. Leaked references are another huge headache.
I also don't think it should be in java.lang.ClassLoader, but we should leave it up to the classloading folks to decide. In case the functionality ends up in a public API in a vendor specific package (e.g. com.sun.* or something similar), I think this should still work for you. - Stanley
