我见过的所有Java项目都使用了一个跟在包结构之后的文件夹结构。这导致我有大量不包含任何文件的文件夹。
因此，例如，包以com.mydomain.mysystem.myutility开头。这将导致文件夹src\com，src\com\mydomain，src\com\mydomain\mysystem不包含任何文件。最有可能myutility也只包含文件夹。
很可能还会有一个包含名称myutility的项目文件夹，因此完整的文件夹路径可能是myutility\src\main\java\com\mydomain\mysystem\myutility\otherfolder
这种做法很常见，但它让我们想知道它有多么有用。与未创建这些额外文件夹的情况相比，有什么好处？使用例如myutility\src\main\java\otherfolder
它似乎同样有效，但它为每个人节省了额外的导航步骤。我可以使用这两种方法编译Java源文件。
在项目中，通常所有来源都在com\mydomain\mysystem。将这些“空”文件夹放在所有项目中有什么好处？
为了清楚起见，我并不质疑包结构的有用性。 Maven也很清楚。
问题是为什么我们在组织的整个存储库中使用通常相同的空文件夹。
答案 0 :(得分：2)
源（和类）文件的组织方式类似，以便Java编译器（和运行时环境）可以找到它们。
当Java编译器编译您的类时，它需要您的类所依赖的每个类的源文件或类文件，以便它可以检查该类是否存在，是否使用正确的参数调用所有方法等。 ，如果找到源文件而不是类文件，或者类文件比源文件旧，它将编译您使用的类的源文件。
编译器当然可以只检查类路径的所有子文件夹，甚至是整个磁盘，但这需要花费很多时间。由于此约定，编译器只需检查每个类路径条目的单个子文件夹。当然，你可以想到这个问题的不同解决方案，但是（当时）Sun的人认为这是最好的选择。
当然，上面也适用于在运行时加载的类文件，因此类文件也存储在类似的文件夹结构中。
另请注意，Java应用程序和库通常打包为Jar文件（基本上是一个内部具有相同文件夹结构的zip文件），因此在许多情况下它们在文件系统中显示为单个文件。
答案 1 :(得分：0)
这样做的原因是为了防止冲突并确保可以唯一地识别类。这意味着如果2个类具有相同的名称，它们仍然可以通过不同的导入加载。
最安全的方法是使用域名，这本质上是唯一的：
例如 com.google.<classname>。
您的方法将起作用并保存一些空文件夹，但不可扩展。