Summary
I've noticed a lot of wrong statements about how java source files must be in a directory tree mirroring the package name. In fact, eclipse gets it wrong, and the developers refuse to fix it!

---

Advertisement

I have been trying to find a new Java IDE to replace my discontinued favorite, Kawa. While doing this, I have tried to take my largest Java applications, 400-600 class files and add them into various IDEs to see how they deal with large projects.

I recently downloaded and tried this with Eclipse and was surprised to find that it flat out ignores the package statements in my source files! I fired off some postings to the eclipse.org news groups and was greeted with a bunch of comments from individuals that believe that you have to put your source files in to directory structures that mirror the package names!

I went out to the Java specification and quoted parts of 7.3 and 7.4 related to the fact that the package statement in the source file is the package that the class belongs in. There is text elsewhere that states that the class files need to be distiguishable by package so that the JVM can find a class easily. There is also text about storing class files in a database, which is not a file system.

YOU DO NOT HAVE TO STORE YOUR SOURCE FILES IN A PACKAGE STRUCTURE!

NO, REALLY YOU DON'T!

Anders Hejlsberg in [http://windows.oreilly.com/news/hejlsberg_0800.html] even said "In Java, the packaging is also your physical structure, and because of this a Java source file has to be in the right directory...", so he doesn't understand this issue either.

Your class files are in a structure that allows them to be located by the JVM, what ever its requirements are. Your source file locations can be arbitrary!

How will the compiler find source files

Many people ask things like, "How will the compiler find the appropriate source files to compile if it can't go to the file based on the package name?" I tell them the compiler should, and must compile the list of source files that I give it. It should use the class path to resolve class files that there are no sources for, and it should write the class files out based on the compilers arguments and the vendors implementation.

The javac compiler has the '-d dir' argument that causes the compiler to write the package structure out start at the indicated directory and going down from there.

Imagine that if the compiler only compiled source files that had explicit references in them. What would happen for classes referenced only by Class.forName()? They wouldn't get compiled! That would be bad!

Others have told me that when the source and the class file are in a package named directory tree, that incremental builds go faster because the compiler can check dependencies and find the source file to open and recompile if it detects such a need. The problem is, that as soon as you introduce a SCC (source code control) system, you can not count on source file dates to drive incremental builds. You have to take into account that some SCC operations might get an older version of a source file that someone wants to build with, and a simple date check will not detect that the source file needs to be recompiled.

For this very reason, IDEs should support either rebuild all, or compile this file, and that is all.

There are several other scenarios where smart compiler tricks with dates and paths do not work either. If an IDE wanted to keep MD5 checksums of every source file, and then compile based on the checksum changing, that would create a nearly bullet proof incremental build.

What's up with Eclipse?

The Eclipse problem really grates on me. The funny thing is that when I compile my large projects, I see messages from the compiler stating that the package statement does not agree with the directory. And I have to ask "So why not just use the package statement?"

Have you made changes to your package structures? Do you think the IDE should force you to structure your source files in some particular way? Do you want to add random source files from other projects to your current project so that you can debug an interaction more readily?

Does your IDE stay out of your way, or force you to work in a particular, contained way?

Talk Back!

Have an opinion? Readers have already posted 19 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Gregg Wonderly adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments.