What is best practice (and implications) for packaging projects into JAR's?

Question

What is considered best practice deciding how to define the set of JAR's for a project (for example a Swing GUI)? There are many possible groupings:

JAR per layer (presentation, business, data)

JAR per (significant?) GUI panel. For significant system, this results in a large number of JAR's, but the JAR's are (should be) more re-usable - fine-grained granularity

JAR per "project" (in the sense of an IDE project); "common.jar", "resources.jar", "gui.jar", etc

I am an experienced developer; I know the mechanics of creating JAR's, I'm just looking for wisdom on best-practice.

Personally, I like the idea of a JAR per component (e.g. a panel), as I am mad-keen on encapsulation, and the holy-grail of re-use accross projects. I am concerned, however, that on a practical, performance level, the JVM would struggle class loading over dozens, maybe hundreds of small JAR's. Each JAR would contain; the GUI panel code, necessary resources (i.e. not centralised) so each panel can stand alone.

When I say "holy grail of reuse", I say this more because it demonstrates a cleanly decoupled, encapsulated design, rather than necessarily expecting its re-use elsewhere. I consider myself a "normally intelligent" person; I consider the spagetti of intertwined nonsense I've had to deal with during my career slows me down 10 to 100-fold. A cleanly decoupled design allows me to deal with one concept at a time, one layer, one class.

Does anyone have wisdom to share?

Answer 1

I would recommend as fewer JARs as possible.

The logic behind it, the disk storage is the cheapest commodity there available, but time spending tracing down complex dependencies is priceless.

Hence the emergence of the .war files where all dependencies of the web application are put into a single file.

BTW, Eclipse has a JAR exporter plugin which puts all dependent jars into a super jar and expose the entry level main method, so you can start your app with java -jar file.jar command. Although the resultant jar may be large, the flip side is not maintaining very complex class paths for you application.

So, in your case I would go with one jar per project. If you determine that you indeed need to reuse some code in another project, just refactor it into the base project and make it a dependency in your existent project and another project.

Answer 2

You can actually use both approaches. Spring for example offers a big monolithic jar file, which contains most common functionality. If you want however you can also download independent jar files. It is then left to the user to select what is best. Big jar files are easier to deploy, but they are harder to upgrade. Also you may need to add a big jar whereas you only need a simple class. I find that is is easier to spot dependencies with small jar files. I also thinK that updating/upgrading is easier.