I’ve got some classes that look for resources on the classpath. When run under Gradle, the class loader appears to be VisitableURLClassLoader(ant-and-gradle-loader). That class loader doesn’t seem to have “my” jar files on it. Is this a configuration problem, a bug, a feature, or user error?
Gradle has a rather deep class loader hierarchy.
ant-and-gradle-loader is almost at the top, just containing the Ant and Gradle classes. (Actually the parent has the ant classes and that one adds all the libs from the Gradle distribution)
Classes from plugins and so on are on lower nodes in the classloader hierarchy, about 4 or 5 levels deeper at least.
So you probably get the class loader from the wrong class or something like that, for example if you get it from Gradle class, you will get that class loader.
I’ve seen it twice in the last couple of days. Once it was coming from Thread.currentThread().getContextClassLoader() so I’m not sure what to do about that. I’m still investigating the other case. But in both cases, these are classes that know nothing abou the fact that they’re running under Gradle but when they are, they can’t find the resources they need.
In the other case, it’s getClass().getClassLoader() and again, I’m not sure how to work around the fact that under Gradle that gives me a class loader that can’t access the resources I’d like to be able to access.
I don’t know about whether and when the contextClassLoader is set and why it should be set to the almost top-level of the classloader hierarchy. Normally it is set to something deep in the hierarchy, so that some code that comes from a higher class loader can access classes from that lower class loader it usually couldn’t access. It would need some debugging to see what is going on there.
About getClass().getClassLoader(), the question is as I said above. On what is that called. If it is called for example on an instance of Gradle or any other class coming from Gradle, that class loader is expected and that it cannot find your resources is also expected. If the instance you call it on is some class of your plugin, then it would be highly questionable why you get that class loader. But wihtout the concrete code, I cannot say much more about it.
I’ll see if I can construct a test that’s not too complicated.
1 Like
Sigh. The “simplest test” I could construct…doesn’t exhibit the problem. grump I guess I’ll have to work backwards from the repository that fails and try to strip it back to the smallest thing I can. Maybe I’ll find the problem along the way. But that’s going to take longer.