JVjvilk·Jun 30, 2014
(Apologies in advance if I am misunderstanding the complaint -- I'm assuming 0 prior knowledge on your end, so my write-up below may sound obvious! Sidenote: I've written a JVM, so I've gained an appreciation for some aspects of the JVM, including class resolution [0].)
In Java/the JVM, file names unambiguously correspond to your package/module/class names. Given a full class name (e.g. java.lang.String) and the class path (a list of folders/JAR files), the JVM is able to locate the specific file with the implementation of that class. This feature is crucial to how the JVM performs dynamic classloading, as classes can reference other packages/classes with a simple string, and the JVM will fetch the relevant class dynamically at runtime.
For example, in the parent comment, gov.nasa.arc.spife.core.plan is the package name, which translates
Read the rest
to the folder /src/gov/nasa/arc/spife/core/plan/. This package name, while verbose, makes sense for NASA, as it corresponds to that organization's hierarchy. gov.nasa corresponds to NASA, arc = NASA's Ames Research Center, spife is probably the project name, and then the rest correspond to packages in that project. This hierarchy makes it clear who has the right to modify particular hierarchies of the namespace, allowing employees to make new packages within their levels of the hierarchy without worrying about name collisions.
As a concrete example, it would be troublesome if every research lab decided to use the gov.nasa.util package name. Or worse -- just 'util'. If both of these are libraries, it's feasible that a client application might use both of them... but then the application will discover that it is unable to use both due to a simple naming conflict in library code!
I agree that it appears cumbersome and wasteful to those used to editing on the command line (as the files are scattered all over the file system), but it's less visible when using an IDE that coalesces empty folders together.
[0] https://github.com/plasma-umass/doppio