I’m currently trying to load classes into my application so that I can then filter out those that don’t contain any test /
@Test-methods. I want to run these tests in my application afterwards.
So far, so good – except it seems like the
URLClassLoader I’m using (or probably any
ClassLoader) doesn’t actually reload classes that are located on my applications classpath.
More precisely, a user of my application starts by selecting a number of
.java source files. Those are then copied to a temporary location and a number of regex match/replace pairs are applied to the copy of the original source files. Next, the copies are compiled, and I then want to load those compiled
.class-files into my application so I can run them as tests.
In most cases, this works as desired.
Unfortunately, if the fully qualified class name (FQCN) of any of the selected files is identical to the FQCN of a class that is part of this application (such as tests for this application), the
ClassLoader ignores the specified path (to
%temp%myfolder) and the (updated) version of the class file located there, but instead uses the already present/loaded version of the class.
After some research, this behaviour can be expected according to the docs (emphasis mine):
• The loadClass method in ClassLoader performs these tasks, in order, when called to load a class:
– If a class has already been loaded, it returns it.
– Otherwise, it delegates the search for the new class to the parent class loader.
– If the parent class loader does not find the class, loadClass calls the method findClass to find and load the class.
I tried using
findClass, but it’s unfortunately not visible.