Kirk Knoernschild (who has created an interesting utility called JarAnalyzer that identifies dependencies among jar files) questioned how it could be possible to manage all the dependencies at lower-than-jar (like package) levels – aren’t there just too many dependencies? Nah…
All dependencies, at any level, roll up from specific lines of code. And yes, if you take a flat view of the world, there are an impossible number of dependencies to control.
However if you use the package hierarchy not just as an extension of the file-system, but as a “design” (or whatever term you prefer, I like “structural control”) medium, then the principle of divide-and-conquer can work as in any engineering discipline. If, at every point in the package hierarchy you have a “mind-sized-chunk” of design breakout, a scaleable design process is possible since the volume of dependencies to be controlled is drastically reduced.
For example, if we have a flat (i.e. just one level of “hierarchy”) package design, and in a development iteration Class A.B becomes newly dependent on class X.Y, this has no “design” impact if there was already a dependency from any class in package A to any class in package X.
The volume of notable design changes is further reduced dramatically if we use a hierarchical package design since a new code-level dependency is now notable only if it creates a new dependency between 2 high-level packages *.P.Q.* and *.P.R.* if none of the code in any of the subpackages of Q previously depended on any of the code in any of the subpackages of R.
Controlling this quantity of dependencies is possible if you have a way of *seeing* how the dependencies roll up through the package hierarchy and a way to automatically detect the introduction of a notable dependency (Structure101 does this, naturally).
Of course, whether you want to keep the structure as-is on a project in which it has been out of control for a long time is a whole other question… more on this later.