What are the best practices (and implications) for packaging projects in a JAR?

Question

What is considered best practice determining how to define a JAR set for a project (e.g. Swing GUI)? There are many possible groupings:

JAR for each layer (presentation, business, data) GUI toolbar (significant?). For a large system, this leads to a large number of JARs, but the JARs (should be) more reused - fine-grained JARs for the "project" (in the sense of the IDE project); "common.jar", "resources.jar", "gui.jar", etc.

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

Personally, I like the idea of ​​a JAR for each component (for example, a panel), since I'm insane in encapsulation, and the holy grail of reuse on projects. However, I am concerned that at a practical level of performance, the JVM will struggle with loading classes in dozens, maybe hundreds of small JARs. Each JAR will contain; GUI panel code, necessary resources (i.e. not centralized), so each panel can stand alone.

When I say the holy grail of reuse, I say this more because it demonstrates a purely decoupled encapsulated design, and does not necessarily expect to be reused elsewhere. I consider myself a “normally smart” person; I believe that the spaghetti of intertwined nonsense that I had to deal with during my career slows me down 10-100 times. Clearly decoupled design allows me to deal with one concept at a time, one layer, one class.

Does anyone have the wisdom to share?

Answer 1

I would recommend as little JAR as possible.

The logic behind this, disk storage is the cheapest product available, but spending time tracing complex dependencies is priceless.

Consequently, the appearance of .war files, where all the dependencies of the web application are placed in one file.

BTW, Eclipse has a JAR exporter plugin that puts all the dependent banks in a super bank and exposes the basic entry-level method, so you can launch your application using the java -jar file.jar . Although the resulting jar can be large, the flip side does not support very complex class paths for your application.

So, in your case, I would go with one bank to the project. If you decide that you really need to reuse some code in another project, just reformat it to the base project and make it dependent on the existing project and another project.

Answer 2

In fact, you can use both approaches. Spring, for example, offers a large monolithic jar file that contains the most common functions. If you want, you can also download independent jar files. Then the user is given the right to choose the best. Large jar files are easier to deploy, but harder to update. You may also need to add a large jar, whereas you only need a simple class. I find it easier to define dependencies with small jar files. I also want the update / update to be easier.

Answer 3

Java provides encapsulation and reuse at the class level - the jar file format does not actually provide it. I do not see a big advantage in creating a significant component in my own bank, if you do not think that many people will download it.

Answer 4

I read somewhere (and tried to find it when I found this) that the project for each layer is the best. This is what I did. Struts, Spring MVC, Swing, no matter what is at one level, EJB at another, business services at another and DAO at another. I put all the DTOs in my own project, even if they are not a layer, but instead passed through layers. The main advantage that I remember was that he could produce each jar separately. Oh, and BTW, on each layer there are actually two banks, one for interfaces that use the level described above, and the other for implementation (s).