1

All Java projects I have seen use a folder structure that follows the package structure. This results I large number of folders that do not contain any files.

So for example packages start with com.mydomain.mysystem.myutility. This would result in a folders src\com, src\com\mydomain, src\com\mydomain\mysystem that do not contain any files. Most likely the myutility will also only contain only folders.

Most likely there will also be a project folder that contains the name myutility so the complete folder path could be myutility\src\main\java\com\mydomain\mysystem\myutility\otherfolder

This practice is very common but it makes we wonder how useful it is. What is benefit compared to the situation where these extra folders are not created? Using for example myutility\src\main\java\otherfolder

It seems to be just as valid but it saves everybody the extra navigation steps. I can compile Java source files with both approaches just fine.

In a project typically all source is in com\mydomain\mysystem. What is the benefit of putting those 'empty' folders in all projects?

Just to be clear, I am not questioning the usefulness of package structure. Also Maven is clear.

The question is why we use the empty folders that are typically the same throughout the repository for an organisation.

onknows
  • 6,151
  • 12
  • 65
  • 109
  • Maybe this answer will shed some light: http://stackoverflow.com/questions/1510291/eclipse-java-project-folder-organization/1510717#1510717 – Adriaan Koster Apr 19 '16 at 11:50
  • Trust me it's better than the alternative where you have to manage it all yourself. Did that with `make` and friends for 25 years, never again. – user207421 Apr 19 '16 at 11:56

2 Answers2

2

The source (and class) files are organized like that so that the Java compiler (and the runtime environment) can find them.

When the Java compiler compiles your class, it needs the source or class file of each class that your class depends on, so that it can check that the class exists, that all methods are called with the correct arguments, etc. Also, if it find a source file but not class file, or if the class file is older than the source file, it will compile the source file of the class you use.

The compiler could of course just check all subfolders of your class path, or even the entire disk, but that would take a lot of time. Because of this convention the compiler only has to check a single subfolder for each classpath entry. Of course you can think of different solutions to this problem, but the people at (then) Sun thought this was the best option.

Of course, the above also applies to the class files which are loaded at run-time, so also the class files are stored in a similar folder structure.

Note also that Java applications and libraries are often packaged as a Jar file (which basically is a zip file with the same folder structure inside), so in many cases they appear as a single file in the file system.

Hoopje
  • 12,677
  • 8
  • 34
  • 50
  • 1
    Or the compiler could just be given the filenames of everything it should compile - as happens in many other cases... – Jon Skeet Apr 19 '16 at 14:12
  • 1
    @JonSkeet Yes, as I wrote in the answer, other possibilities exist. I think the folder structure scheme makes more sense for finding compiled class files, and given that, it makes sense not to use a completely different scheme for source files. In practice, the whole thing is not important, because the IDE manages the folder structure for Java source files, and the list of sources supplied to the compiler for other languages. – Hoopje Apr 20 '16 at 06:14
0

The reason it is done this way is to prevent conflicts and ensure that classes can be uniquely identified. This means that if 2 classes have the same name they can still be loaded via different imports.

The safest way to do this is by using a domain name, which is by its nature unique:

com.google.<classname> for example.

Your approach will work and saves a few empty folders but is not scalable.

StuPointerException
  • 7,117
  • 5
  • 29
  • 54
  • 1
    It scales fine when all the source files (and bear in mind that's all that's being asked about here - source files) will have the same prefix. The convention in .NET is for the "root" directory of a source hierarchy to represent a particular namespace, and directories are added for "sub-namespaces" within that. Works absolutely fine. – Jon Skeet Apr 19 '16 at 11:54
  • @Jon Skeet, out of interest do you think the same approach would work in the Java world where, from my experience at least, projects tend to rely on more third-party libraries? – StuPointerException Apr 19 '16 at 12:01
  • 1
    Yes, absolutely - because you don't typically put your third-party libraries in with your source code, do you? Bear in mind that this isn't suggesting a change of package name, *just* of source file layout. Why would using a third-party library interfere with that? It's very important to distinguish between "fully qualified name" and "folder hierarchy of source files". – Jon Skeet Apr 19 '16 at 14:12
  • 1
    The source file layout discussed (`myutility\src\main\java\otherfolder`) is a package change, the only valid Java package for that layout is `otherfolder` since everything else results in a compile error: `package x does not correspond to the file path y`. – StuPointerException Apr 19 '16 at 15:15
  • 1
    Nope - or at least, it doesn't have to be, and `javac` doesn't force it to be. If you're using a compiler that *does* enforce that rule (not present in the JLS as far as I can see) that's your choice. Personally I think it's a pity - I definitely prefer the .NET approach. – Jon Skeet Apr 19 '16 at 15:17
  • 1
    Ah, I see, that makes sense. Thanks for the information. – StuPointerException Apr 19 '16 at 15:23