My Stuff

2010 Conferences

OSGi DevCon @ JAX London

February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox

EclipseCon

March 22 - 25 - Tutorial on Modular Architecture

Tweets @ Twitter

Why must I be logged in to Google to simply view the #nexusone http://www.google.com/phone... They wanna know what I'm looking at? #odd 4 days ago

RT @nhajratw enlightening and surprising post on #lean swdev at #toyota http://bit.ly/cmgGAp #agile 5 days ago

Whoa... Just had major epiphany. Big lightbulb just came on. Blog post to follow soon. 5 days ago

#apple selling 25,000 iPads per hour. http://bit.ly/bpgr3R 1 week ago

Cost of U.S. Census http://bit.ly/9AsimE Let me help. Select COUNT(distinct id) from the_people; I'll take my 14 billion now! 1 week ago

LinkedIn Profile

The opinions expressed on this site are my own, and not necessarily those of my employer.

Apr '09
8

A Question on JAR Design

Filed Under Architecture & Design, Development, Java, OSGi |  

A while back, I posted about Jar Design over Class Design, which summarizes the responses I’ve gotten over the years when asking developers where they devote the majority of their design activity. The responses I get are always consistent - time is spent on class design, not JAR design. In fact, few teams spend time on JAR design.

For several years, I’ve always felt that JAR design is equally, if not more important, than class design. In fact, the majority of postings on this blog talk about modularity, OSGi, managing dependencies, and a lot of other design stuff that’s specifically focused on JAR design. But that doesn’t appear to be mainstream thinking, and I’m very curious, and would appreciate your help. Why do you spend more time on class design, and less time on JAR design? Please let me know.

Comments

5 Responses to “A Question on JAR Design”

  1. Pete Haidinyak on April 8th, 2009 3:29 pm

    Usually deployment is left to the last. I am porting my application to OSGi and agree a good JAR design is important and necessary.

  2. Nayan Hajratwala on April 8th, 2009 9:32 pm

    You start thinking about jar design more when doing end-to-end stories and continuous deployments from the start.

    If you’re not doing end-to-end, deployment tends to (unfortunately) be an afterthought, and by then untangling your mess of classes into reasonably packaged jars is just too difficult — especially if there are no tests, yada yada yada…

  3. Craig Tataryn on April 8th, 2009 10:45 pm

    Just my two cents, I think the MANIFEST.MF file is one of the most misunderstood files in Java. Can you actually find a good explanation of this file that’s specific enough to make any sense?

    Then you get IBM and their weirdo files, it’s just a mess.

  4. Mirko Jahn on April 9th, 2009 12:09 am

    I think the problem is based on the history and the issues with the JAR specification. JARs in the past have been nothing more than containers for source code, relevant only for deployment. There was no additional value in separating code in different JAR files other than having a distribution format.

    When looking at “legacy” applications, what you’ll find are pretty course grained jars containing way more than current bundles contain. If you have a separation in place it usually consists of an API and an implementation JAR. Till OSGi came along, there was no point in having a really fine grained componentization based on JARs. It was just a hastle. With JARs you usually had to ask yourself what other JARs do I need, so why making it overly complicated by separating it further? There was no isolation, no versioning, no lifecycle, nothing like we got with OSGi.

    In my opinion, with OSGi for the first time we have a real benefit in modularizing the source code. With repositories to automatically find and install bundles there is no longer a real issue with the amount of JARs floating around in your application. Look at Eclipse and the number of JARs and think of what a burden it would have been in plain old Java applications to manage all these (creating the correct classpath with the right order, shadowing problems, etc.).

    Concerning the question about thinking of modularization (separation into JARs), people thought they already have modular systems, but in fact until it is enforced (like in OSGi), you’ll never “really” achive it. So I think with OSGi people first started thinking about the benefits of “real” modularization. While migrating legacy applications I’ve seen quiet a few unknown circular dependencies, layering violations, implementation dependencies when not necessary,…. People now see and feel the benefit and are more forced to think about their design, which wasn’t required before. Modularization now (with OSGi) can be felt by the developer and so he (or she of course) is more likely to take action and use appropriate modularization techniques.

    Just me humble thoughts ;-)

  5. Ian Sutton on April 9th, 2009 2:24 pm

    I couldn’t agree more with your basic premise that design really has to incorporate levels of abstraction above the class.

    One of my favorite software quotes is Jonathan Edwards saying that “the human mind can not grasp the complexity of a moderately sized program, much less the monster systems we build today”. If all we have to go on is classes, gazillions of ‘em, then I’d find it very hard to argue with him. However, I do think that the application of design - as a form of recursive divide and conquer - can crack the complexity nut.

    Where I might diverge a little from you, however, is the emphasis on jars. Personally, I’d tend to view this more as a continuum up through the e.g. package structure, rather than taking a single leap from class straight to the rather coarse-grained level of jars.

    So happens I’m ambling through a little set of (rather esoteric) posts on this subject myself. You might find them interesting…

    http://www.headwaysoftware.com/blog/2009/03/watchmakers-parable/
    http://www.headwaysoftware.com/blog/2009/03/holarchy-101/

    Cheers,
    Ian

Leave a Reply




Recently Written

Categories

Archives