4 ms·

The classloader at runtime has to get its configuration from somewhere; that configuration is usually a static list of jars in a folder. That long list jars in

The classloader at runtime has to get its configuration from somewhere; that configuration is usually a static list of jars in a folder. That long list jars in the WEB-INF/lib folder doesn't magically appear. Maven and Gradle have everything to do with runtime classloaders working properly and at-scale. Most developers don't know (or care) about all their transitive dependencies that get slurped into their projects.

cocoapocoa 9y ago
What you've described is just one way a classloader can work, however, they can be implemented or hacked upon in a variety of ways. Sure - maven does the work of resolving/flattening the dependency graph and downloading the libs - but it simply isn't a classloader. That said, it might be possible to write a custom classloader which uses some bits of maven internally (provided there is a package to GAV index somewhere).
- EdSharkey 9y ago
  > Sure - maven does the work of resolving/flattening the dependency graph and downloading the libs - but it simply isn't a classloader. Well, of course, but when was the last time you manually configured your classloader? How divorced are your classloaders from Maven, practically speaking? (That's what I was getting at - I wasn't trying for some pedantic sort of "maven constructs my java.lang.ClassLoader objects"-type thing.) By manually, I mean supplying a list of .jar files and folders, or writing code that pumped classes into a custom classloader? Practically speaking, for any non-toy-sized project most people don't bother with that business anymore. They make deployment units, uber/shadow jars, or launch from a tool like Gradle that rolls their classloader for them from a Maven repository. > That said, it might be possible to write a custom classloader which uses some bits of maven internally (provided there is a package to GAV index somewhere). Ant, Gradle, and to a lesser extent, Maven serve as fine Java application launchers in that their dependency resolution engines can be targeted at the classpath-related arguments on the java and javac command lines.

cocoapocoa 9y ago

What you've described is just one way a classloader can work, however, they can be implemented or hacked upon in a variety of ways. Sure - maven does the work of resolving/flattening the dependency graph and downloading the libs - but it simply isn't a classloader. That said, it might be possible to write a custom classloader which uses some bits of maven internally (provided there is a package to GAV index somewhere).

EdSharkey 9y ago
> Sure - maven does the work of resolving/flattening the dependency graph and downloading the libs - but it simply isn't a classloader. Well, of course, but when was the last time you manually configured your classloader? How divorced are your classloaders from Maven, practically speaking? (That's what I was getting at - I wasn't trying for some pedantic sort of "maven constructs my java.lang.ClassLoader objects"-type thing.) By manually, I mean supplying a list of .jar files and folders, or writing code that pumped classes into a custom classloader? Practically speaking, for any non-toy-sized project most people don't bother with that business anymore. They make deployment units, uber/shadow jars, or launch from a tool like Gradle that rolls their classloader for them from a Maven repository. > That said, it might be possible to write a custom classloader which uses some bits of maven internally (provided there is a package to GAV index somewhere). Ant, Gradle, and to a lesser extent, Maven serve as fine Java application launchers in that their dependency resolution engines can be targeted at the classpath-related arguments on the java and javac command lines.