This page came from a discussion of the flaws of the java packaging system on IfSmalltalkIsSoGoodWhyDoesNobodyUseIt. 

First question that might be asked is why do we need code organized?
* To read it. A bundle of code may be placed together to make it easier to understand the system.
* To write it. A systems code can be sliced up into units of work for different developers, to avoid them treading on each other's toes.  These different developers may be located 'round the world. 
* To build it. Code can be organized to remove circular dependencies in order to simplify building it.
* To layer it. A layered architecture gives an obvious way to organize most code - except the bits that move between layers!
* To manage it. Code could be divided into 'stable' and 'unstable' if theres a bit of the system you're working on. Pieces of the system could be moved back and forth between these categories. This kind of organization could be enforced by a bug reporting tool.
* To deploy it.  Many applications are deployed in a piecemeal fashion, with executables and DLLs and jar files and the like scattered all around.  In some cases, this is overly complex; but it facilitates code sharing and CodeReuse and allows various OperatingSystem optimizations (if two applications are statically linked to foo.o, then each has its own copy in memory; if they both use foo.so then only one copy need be present).

This is off the top of my head. I'm hoping TomStambaugh has a better list!
----
Java Packages

A classic rooted tree. Tied to the filesystem; being WriteOnceRunAnywhere it assumes a lowest common denominator filesystem - no SymbolicLink''''''s or wacky mounting of directories (see WhatIsNotInPlanNine)

Using packages is even less comfortable than a filesystem - you must either refer to stuff in the current package, or declare dependencies using absolute paths. You can't eg refer to foo.Circle if foo is a subpackage of the current one. While java class files do actually declare explicit dependencies, the 'import foo.*' syntax allows java developers to easily declare dependencies on things they don't depend on.

The code organisation represents the view of the original developer of the best way to organize the code. There is also a feature in java that the 'protected' keyword allows access to some things within the current package that classes outside the current package can't reference. However, this is rarely the reason for a given package organization. No other views of java code are available.
----
''While some of this is a problem, the lack of explicit dependencies can be useful. An example is the lack of an explicit dependency on the core packages ('java.*'). If the dependency was on an explicit version, then code cannot be used on later VMs, or on alternate VMs (e.g. you could not develop code on a desktop VM and use it on the palm KVM). Jar isn't in the metamodel because that whole mess (filesystems, classpaths, etc) is meant to be abstracted out by your ClassLoader, which you can change, to e.g. fetch classes from the network, or build them on the fly from a stream of bytes you generate. Package doesn't have dependency methods because dependencies are at the class level (which I agree is a lousy way of organizing things)''

None of the prior objections to Java packages bother me. Except for package permission, which most programmers don't use, packages are simply a way of partitioning Java classes into separate groups. They act as a namespace, which is convenient when using third party code. Their main benefit is making the code more comprehensible. A more explicit superstructure, such as explicit package dependencies, doesn't seem necessary.

----

A RelationalWeenie viewpoint is to use database techniques to group the code by whatever grouping a given person wants. Individuals would use query techniques to produce the view they want for a given issue or developer task. There is no one-size-fits-all "correct" view. However, a few issues remain:

* What granulatiry should the code chunks (cells) be?
* Will compilers/interpreters be built/tuned that can easily use the database the way they now use file systems (also a sort of database)?
* How can packaging be arranged so that parts or components can be moved around to different systems, updated, etc. For example, a given component may use multiple tables, some shared with other components and some dedicated (custom made) for a given component. A standard needs to be divised to insert, remove, and update these as "packages". In some ways this resembles the Microsoft Registry arrangment, which has some unpleasentries associated with it that need to be worked on. (The Registry is not relational, by the way.)

----
CategoryCodingIssues