There are many nice tools out there that do help you to manage all your sources and packages. Use Netbeans and you don't have any problems in creating/managing packages.

I think it is very important for all good programmers to understand packages and why and how to use them. It is very easy to write software but it is very hard to write good software...

And for the zero-based arrays: it is intuitive and helpful in many ways. For example does it help you in using modulo for ringbuffers or something like that.

Although I have to say I like the partial class feature of .net. The typical use is to add your own functionality to generated classes, which is nice if you do domain driven design. No stunts with inheriting from generated base classes required.

A similar feature for java would be helpful, maybe by compiling sources from multiple source trees (e.g., from src/my/package/TheClass.java and generated/my/package/TheClass.java) into a single class file.

You want a discussion. Let's have a discussion.

Give me one reason why putting the class com.weiqigao.discussion.Topic in com/weiqigao/discussion/Topic.java is better than putting it in just discussion/Topic.java.

"It's better because that's the way it works." doesn't count as a good reason.

Why would I want to have both a com.weiqigao.discussion.Topic and a com.anotherguy.discussion.Topic in the same source tree? Even if I have both, I can use some other directory structure to segregate them.

No imagination is necessary. There are plenty of projects written in OO (or other) languages without this feature. Most of the successful ones are well organized.

Because Java picked a structure, there are not thousands of different conventions (one for each project out there). This makes it dramatically easier to navigate java source code, regardless of whether you're familiar with it or not. It removes endless arguments about what the structure should be. It lets every Java programmer find sources (and classes) quickly and know that what they are looking at is what they want to look at.

I bet this has saved literally thousands of man-years when measured across just the span of all developers working in Java during it's lifetime so far.

In my last example, the "/com/acme" portion of the directory structure is arbitrary and excessive and wasteful and irritating and serves no useful purpose what-so-ever, given that every thing in the project falls into the com.acme.* package hierarchy.

I'm not advocating putting everything into one directory. I'm not advocating organizational structure per project. I'm advocating a freer and more reasonable use of directories as an organizational tool.

You don't see this explicitly mentioned because "directory==package" is ingrained in peoples head for so long and so hard that they don't even think about the differences any more.

All that I'm saying, people, is that when you work in the Marketing devision for the Mexico City branch of the GUI Research subsidiary of the International Widget and Gadget company, which uses the internationalwidgetandgadget.com domain name, and you are writing a billing application, where all your classes must live in the (I put some spaces in the package name so that it will wrap instead of going all the way to the east coast) package

com. internationalwidgetandgadget. guiresearch. mexicocity. billing

com/
  internationalwidgetandgadget/
    guiresearch/
      mexicocity/
        billing

It doesn't make sense to put everything in a

com/
  internationalwidgetandgadget/
    guiresearch/
      mexicocity/
        billing

directory hierarchy.

billing

com/
  internationalwidgetandgadget/
    guiresearch/
      mexicocity/

I'm not sure that such a scheme would be without its problems (Maybe someone could point them out)

Personally, I don't mind creating the extra directories - I simply consider it to be specifically stating my intent, rather than leaving other developers to guess what I meant.

Don't Repeat Yourself (DRY) and coding by convention are compliments.

DRY is a heuristic, not an ideology.

With all design, we engineers have to balance competing constraints and goals. Hence the conflict. Though, I have to admit, that it would have never occurred to me to question/challenges Java's obviously correct design choice to have isomorphic packages and file structure. This innovation has been an unqualified good.

Perhaps these spurious tangents are productive, if only to remind us why things are the way they are, so that we don't take it all for granted.

Cheers, Jason