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

Posted by user245510 on Stack Overflow See other posts from Stack Overflow or by user245510
Published on 2010-03-23T11:39:23Z Indexed on 2010/03/23 11:43 UTC
Read the original article Hit count: 370

Filed under:
|
|
|
|

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.

    Does anyone have wisdom to share?

  • © Stack Overflow or respective owner

    Related posts about java

    Related posts about swing