将项目打包成JAR的最佳实践（及其影响）是什么？

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 (eg 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 (ie 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.

Answer 3

Java provides encapsulation and re-use at the class layer - the jar file format doesn't really provide it. I don't see much advantage in putting a significant component in its own jar, unless you think lots of people will be downloading it.

Answer 4

I read somewhere (and I was trying to find it when I found this) that project per layer is the best. It's what I've been doing. Struts, Spring MVC, Swing, whatever in one layer, EJBs in another, business services in another and DAOs in another. I put all of the DTOs in its own project as well, even though they don't represent a layer, but are instead passed through the layers. The main benefit I remember reading about was being able to version each jar separately. Oh, and BTW, each layer actually has two jars, one for the interfaces that the layer above uses, and another for the implementation(s).