Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

JAR Design Over Class Design

  • submit to reddit

In early December, I spoke at SpringOne Americas and delivered a session on OSGi. Whenever I speak about application design or architecture, I always ask the audience three questions at the beginning of the session. In this session, I had about 40 or 50 folks in attendance, and here’s a rough breakdown of the hands shown after each of the questions.

  • How many spend time designing classes, both the behavior of a class and the relationships between classes? Almost everyone raised their hands.
  • How many spend time designing packages, both the behavior of a package and the relationship between packages? Only about 5 hands went up.
  • How many spend time designing JAR files, both the behavior of a JAR and the relationship between JAR files? Only about 2 or 3 hands went up.

These are common responses. Most development teams spend time designing classes, but few spend time designing JAR files. That’s unfortunate, because failing to design JAR files inhibits reusability and hinders maintenance. Even the most flexible class design is severely compromised if all classes are packaged and bundled into the same module.

When designing software systems, more effort should be devoted to designing the granularity of JAR files and managing the relationships between JAR files. When designing classes, more effort should be devoted to designing classes whose relationships
span JAR files, with less effort devoted to classes whose relationships
are encapsulated within a JAR file. Why? Classes whose relationships are encapsulated within a JAR file are isolated from the rest of the application, and can be more easily refactored because the ripple effect of change is constrained to the JAR file. Packages, as the intermediary logical concept, are important in helping bring greater internal design resiliency to a JAR file.

And, of course, design is a evolutionary activity involving many tasks, including a combination of modeling, coding, and testing.


Published at DZone with permission of its author, Kirk Knoernschild.


Thierry Milard replied on Thu, 2009/01/08 - 4:28am

I think perhaps will easier tools to manage/update jars inside tools could help us.


Gilbert Herschberger replied on Thu, 2009/01/08 - 2:47pm

For those of us who have been spending a lot of time working on the design of jars and relationships between jars, what do you think are the basic rules of good jar design? We might start with the following list.

  1. Spend quality time designing a jar. Do not expect a jar to design itself.
  2. Design a jar for future applications and other developers.
  3. Design a best-of-breed application program interface (API)--even for different parts of the same application.
  4. Do not put an API and an optional implementation in the same jar.
  5. Do not put run-time and test-time classes in the same jar.
  6. Provide power-on self-test classes and put them in a run-time jar.
  7. Provide an service provider interface (SPI) for jars that implement services for an API.
  8. Do not distribute an application as one giant jar.
  9. Do not copy classes from a collection of open source jars to create one giant jar.
  10. Provide packages for Java 2, 3, 4, 5 and 6 platforms but do not mix them together in the same jar.

Jar design is an excellent topic for discussion. We need hints, suggestions and recommendations.


Phil Zoio replied on Fri, 2009/01/09 - 4:46am

It does not surprise me that more people didn't admit to designing jar or package relationships - but that's exactly what lead to spagetti code and systems. OSGi and modularity frameworks such as Impala strongly encourage you to think about these things, which is essential if you want to write modular applications.

 A couple of other rules of thumb I'd like to add to Gilbert's:

11. Make sure you eliminate package cycles from your jars.

12. Give each jar it's own base package. For example, foo.jar contains and subpackages. This makes sure that you don't end up with packages split across jars (a no-no in OSGi), and also self-documents the location of packages.

Phil Zoio - Impala dynamic modules

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.