Stephan van Hulst wrote:
The fact that javac chooses to implement a package through folders doesn't mean that I shouldn't be able to plug in my own compiler and project layout that doesn't work with folders at all.
Repeated for emphasis.
On the IBM mainframe computers, hierarchical directories didn't exist*, but certain filename coding conventions could be used as an approximation. You might end up with a disk file named "COM.EXAMPLE.APP.TEST.CLASS" and the next file on the volume set might be name "COM.EXAMPLE.APP.UTILS.JAVA".
That's historical and never happened. For one thing, back when this was the norm, not only were filenames limited to upper-case, they also could not exceed 44 characters. But then, try squeezing a JVM into 24MB of virtual memory. Which was all that even the biggest water-cooled behemoths could manage until
circa 1985.
Point is, the name/paths of Java classes are mapped to directories is that it's convenient in the context of the popular server OS's. You could just as easily store them in cloud objects, as Stephen mentioned, in SQL databases as BLOBs, and so forth. To the best of my knowledge, in fact, nowhere in the Java spec does it require a class to be a file in a directory.
And certainly the classloaders aren't so limited. In fact, a classloader could even construct a class from scratch in memory if it wanted to. The classloaders in webapp servers can pull classes from the jars in the webapps's WEB-INF/lib directory, even though officially a webapp is a WAR, which is a JAR, and the standard Java runtime does not search JARs inside of other JARS for class resources.