Well, if you use maven or gradle, it will manage the classpath for you. If you are doing this manually, you indeed need to read up on how that works. It isn't p

Well, if you use maven or gradle, it will manage the classpath for you. If you are doing this manually, you indeed need to read up on how that works. It isn't particularly hard. It's like a file path; but for class and jar files. It pretty much works the same way. Where the class loading mechanism gets complicated is the notion that it's a run-time thing and that Java allows for loading and unloading things at runtime as well as loading jars and classes into separate class loaders that can each have their own copies of the same; or even different versions of class files. Not a lot of applications actually do that these days but it used to be quite common. I actually used OSGI back in the day (a more powerful module system) that relied on this for managing different components that each had their own dependencies and dependency versions. Neat, but no longer that common to do these days. Osgi actually emerged out of the embedded software devices world. Later Eclipse used it to componentize the Eclipse platform and I know some companies that use OSGi for different things. These days you'd use microservices in some kind of Kubernetes container; or not (I'd consider that overkill for most of the stuff I work on). The Java module system is much simpler and not really intended for this (at least not primarily). Instead, the main use case is ahead of time compilation. Modules allow parking things that can't be compiled (e.g. because of reflection ahead of time in separate modules, which you can then exclude. Breaking up the jvm platform into modules was a big project. As far as I know, they are not that commonly used for anything else. At least, I've not encountered many projects that rely on this. It's a pretty low level mechanism. These days for servers, you package up applications as Docker containers, which contain your application and the full jdk. Both Spring Boot, Ktor, and other modern frameworks are commonly packaged up as single jar applications. Nothing magical about that; they are literally zip files with some manifest listing their content (classes, resources, more jar files). Of course modularizing a single jar application is kind of pointless. Likewise, there is no real need to tweak the java runtime you run it with either. Just not a thing. The notion of stuffing zip files in zipfiles is also a bit weird but it kind of works as a packaging mechanism.