Reputation: 2250
I've a read a couple of questions related to the general problem of unloading/reloading a class at runtime and it seems to be a tricky and somewhat fishy issue. I wonder however what is the case of classes which where explicitly instrumented in the runtime using a separate ClassLoader dedicated to the purpose and don't have any instance (because either the constructor always throws an exception or the class didn't even pass the validation by the JVM)?
I attempt deep mocking of arbitrary domain model class graphs (library code). This is scala, which means these are classes without default constructors and which don't take to null
values kindly in general, so I need to instantiate all arguments (and in turn, often recursively instrument their subclasses). This is obviously going to fail sometimes - how often depends on the coding style and how much validation is peformed in the constructor. As I already face the risk of mocking a much larger graph due to the dependencies that would be advisable, I try to limit myself to a single best shot at generation a class and give up on failure, rather than try different constructors or different values, which could at least in theory increase my success rate.
I am currently using ByteBuddy and considering how comprehensive it is, it seems like somethting it might be already able to do?
Upvotes: 0
Views: 447
Reputation: 44032
As Holger says it, class loaders (and their classes) are unloaded once they become unreachable. By default, Byte Buddy loads all classes into a seperated class loader but you can control this behavior by using an explicit ClassLoadingStrategy
as a second argument to the DynamicType.Unloaded::load
method.
Upvotes: 1