Home/ Questions/Q 685877
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T01:58:02+00:00

What is considered best practice deciding how to define the set of JAR’s for

  • 0

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?

    • Share

    Leave an answer

    You must login to add an answer.

    Need An Account,

    1 Answer

    1. Editorial Team

      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.

      • 0