> you shouldn't have to encode that in the path, just some metadata in a file somewhere would have done the same job There are two problems with this approach,

> you shouldn't have to encode that in the path, just some metadata in a file somewhere would have done the same job There are two problems with this approach, from how I see it. 1) Now there is an extra build step: Produce the metadata that associates class names with files. 2) This mechanism also adds an extra level of indirection when the ClassLoader needs to resolve a class. By using a file system, you can edit a single Java file in a project with many classes, and recompile only that single file to test your changes. > All this code is ALREADY in a folder named gov.nasa.arc.spife.core.plan.editor.timeline That's NASA's choice for organizing code into modules. Each of these look like individual libraries, and that's the full name of the package that the library supplies. Sounds practical, especially since they have the source code of other non-NASA libraries checked in (e.g. rhino). They could have merged the source trees of the individual components, but that becomes cumbersome as some of the third party components are under different licenses, and it's likely that each of these packages are built and packaged into separate JAR files. That folder name won't be in the final JAR file, which will only have the hierarchy past the src folder. Note that the JVM has a robust mechanism for custom classloaders, so you could actually implement your metadata idea if you wanted to. What will happen at runtime is that the JVM will invoke your custom classloader with the full class name (e.g. java.lang.String), and then you have to give it the Class object associated with it (which you can construct dynamically, produce from a byte array loaded from somewhere, or request from the JVM's file-based classloader).