I'm writing a library that uses BCEL internally. My library is intended to be used by applications, which may use BCEL by themselves for other purposes. My library may be deployed into a multi-classloader environment, such as a web container or application server. I found the notion of the singleton Repository (org.apache.bcel.Repository) problematic. When my library is used in a web container, Repository by default fails to load classes in "my" class loader (instead it only resolves classes in the system classpath.) Yet if I change the global Repository._repository instance to ClassLoaderRepository that works with my class loader, it may break my host application that just happens to be using BCEL. The same issue arises when I got multiple threads that each work with different classloaders. I have to arbitrate the use of BCEL among those threads, and it still doesn't prevent someone else from replacing Repository. Here's another way to hit this problem. Suppose you got an Ant task that generates class files by using BCEL. If the user runs this task in parallel with the <parallel> task, classes that are generated from those parallel threads share the same Repository and cause conflicts. In more general terms, when BCEL makes a static method invocation like Repository.lookupClass("org.acme.Foo"), it's assuming that this name resolves to a single class. Unfortunately this is wrong, as we all know that multiple classloaders are allowed to resolve this in different classes.
What if your custom classloader loaded bcel, then you would have n Repositories, no?
I came across the same limitation ...I totally agree the static approach is a real problem