Java Package Structures Considered Harmful

As I get more experienced with ergonomic languages like Ruby, the sharper, stupider parts of Java are coming into sharper relief for me. Fortunately, at least some of these problems are cultural rather than technical, and and can be corrected by simple changes in practices. A great example of this is java package structures.


If you’re a java coder, try this for an experiment some time. Show the file system hierarchy of your source code to a non programmer. You know, the one that goes
->com
->mycompany
->myproduct
->actual package name
I guarantee they will look at you like you’re crazy. What’s the point of all those nested folders? No wonder it takes 10 years to write good software: the programmers are all dorking out on their directory structures rather than actually coding!
The original intent the nested folders was a good one: to avoid namespace collisions by tying your package structure to a url that you own (thus guaranteeing that, as long as you continue to own that url, and everyone follows the convention, there is no danger of your code colliding with a third-party code’s namespace).
But the result is a much deeper file system hierarchy that has to be navigated every time someone opens a file. Here’s a hint: extra cognitive friction that contributes no value is a BAD THING.
Fortunately You can get just as much of a guarantee using the following package struture
com_mycompany_myproduct
->actual package name
The resulting tree is two directories shallower than previously, and much easier to navigate. All new Java code at Uzanto follows this pattern. Not only is it easier to work with, it also LOOKS better.
Thoughts?

2 thoughts on “Java Package Structures Considered Harmful

  1. Dominick Accattato April 26, 2006 / 7:54 pm

    I can understand your reasoning however I side with the current standard. Plus its not even worth worrying about with the tooling that is on the market. Eclipse can show your package structure using hierarchy or flat. Plus I rarely see a project that doesn’t have many different branches/trunks. Now, take for example if you have subprojects..
    com_mycompany_myproduct
    com_mycompany_myproduct_subproduct1
    com_mycompany_myproduct_subproduct2
    com_mycompany_myproduct_subproduct3
    now, your boss tells you that the product name has changed, you have 4 different packages to refactor instead of 1. This is a small example.
    As well, your going against a standard that almost everyone knows. Your going to have to expect that your code will not be the norm. Add third party code to your codebase and your back at square1. I’m sure there are many other examples as well.
    I’m not saying its a bad idea. I’m only saying that its probably not worth the fuss. 😉

  2. Jon April 27, 2006 / 9:45 am

    Dominick,
    Thanks for stopping by!
    If I was in a big shop, my reaction might be the same as yours. To do something different is to call attention to yourself, and you have to pick your battles.
    Unfortunately, these sort of things collectively DO slow development. The geeky quest for the ultimate in loose coupling is often really just a worship of complexity for the sake of complexity. It creates a culture where no one feels comfortable asking questions like “why do we have to configure 12 xml files to get a 3-page web application running” (a la STRUTS).
    Writing software is hard enough. There’s no reason to make it harder. But in order to get there we need to be able to slaughter sacred cows like the Java package structure.

Comments are closed.