Too many jars!
Another recent trend in new projects these days is a profusion of jars. Now, reusability is a good thing, but on the other hand, I’m surprised by how eager developers are to chain themselves to external libraries often written by hobbyists in their spare time.
Unfortunately, tools like maven just make this problem so much worse. Some lunatics had this idea that your dependencies become manageable and controlled once you slap on something like maven. In fact, all maven does is let you live in this fantasy lalaland where you get to pretend your dependency problems have magically been poofed away by a little jakarta fairy.
Case in point (sorry Mike) is JIRA. Lovely tool, works nicely and so on and so forth. However, if you dare, have a peek in the WEB-INF/lib directory. There are nothing less than THIRTY SIX jar files in there. This is more jar files than most appservers require (even if you include spec API jar files like servlet.jar and friends). JBoss of course is a notable exception, which has more jars than Marc Fleury has crayons.
Some of these dependencies have no place being there at all. For example, why is ejb.jar in WEB-INF/lib? How about mockobjects that are only used during testing? bsf AND bsh? A veritable cornucopia of *-DEV.jars, signifying a cvs version pulled in at some point in the past (not hint of when, naturally).
It is this slaphappy ‘oh I need one class that performs this handy util functionality…I know! I’ll bring in the whole jar and everything will be great!’ attitude that is responsible for this jar infestation.
Here is a radical suggestion, THINK about your dependencies. Imagine having to track whatever project you’ve just tied your code to. Imagine having to follow up with releases, bugfixes, changes, and suchlike. Imagine having to test compatibility with every release. Imagine writing all those testcases.
Wouldn’t it be an awful lot easier if you were to just write that piece of functionality, or grab that one class without bringing on all those extra pains?
Give it a shot, pretend it’s fashionable (you read it in a blog, so just blindly follow like you tend to do anyway). Your users will be happier, they’ll get that warm fuzzy feeling of ‘wow, this project’s developers lovingly handcraft their product, they don’t use a sledgehammer for everything they come across during their day’.
July 27th, 2003 at 10:46 pm
“bsf AND bsh?”
BSF provides a generic means for interfacing with a wide variety of scripting engines, whereas Beanshell is one scripting engine. Working with BSF lets users plug in other scripting engines should they desire to do so.
July 27th, 2003 at 11:01 pm
One of the major issues appears to be in using a useful library and then becoming dependent on its dependencies. So if you use a jakarta-commons lib, you suddenly need about a gabillion other jars. Drives me nuts.
July 28th, 2003 at 12:10 am
Mate,
Another JIRA bile-ing - that’s twice - are we the record holders now? :) (PS You owe me sushi again I guess ;))
In general, I agree with you - lots of dependencies can be a pain in the ass. BUT I think it’s only a PITA if you’re developing a component. If you’re developing an end user application, I’m not sure you really care (except where one dependency has dependencies which clash with other dependencies - but that’s a Java problem in general).
Retort:
a) JIRA is an end user application, so realistically our users don’t care about the dependencies, they just want to use JIRA. If we can use an external library to make development faster, they DO care about that. However as you pointed out, being an application that people also integrate (albeit perhaps 1% of our user base does this), there can becoming a problem tracking dependencies like this. I’m not sure that ‘write it yourself’ is a solution though?
b) As for why we ship ejb.jar, bsh.jar, bsf.jar etc - I find the irony amusing. We ship these because JIRA uses OSWorkflow, which I believe you are a a core developer of? *grin* You can easily fix that problem yourself - fix OSWF and we’ll fix JIRA there.
Good post overall though.
Cheers,
Mike
July 28th, 2003 at 2:16 am
Hey Mike… I’m keeping up with ya! That’s 2 for me too! Woo hoo!
July 28th, 2003 at 2:17 am
Oops… this is written after Hani’s next post ws up…
July 28th, 2003 at 8:37 am
+1
Yes, this was one problem with Nanning. But Jon is such a nice guy, I think after some complaints (rather a lot :-) from me he’s down to very few dependencies with Nanning.
July 28th, 2003 at 3:11 pm
Hany said: “THINK about your dependencies. Imagine having to track whatever project you’ve just tied your code to. Imagine having to follow up with releases, bugfixes, changes, and suchlike. Imagine having to test compatibility with every release.”
Now, bundling jars with your application is exactly the OPPOSITE of that. Since you don’t want to follow “releases, bugfixes, changes and suchlike” of all your dependencies, you simple choose a version *that works with your application* and bundle them, voila.
Now, if you really want to keep following every release of your dependencies, it’s up to you. Why Mike stuffed all that -DEV jars with JIRA? Because that version worked, and Mike don’t really want to know if more recent version works. He may try that later. Your application needs not to be compatible with every reelase, just with the one you choose to bundle.
July 29th, 2003 at 9:44 am
Silly me, I thought the point of having freely available lower-level libraries is that you USE them instead of just checking out what they do and replicating their functions in your app. Doing that would seem to give you the worst of most worlds: it’s more code to maintain and you don’t get the benefit of other folks’ continuing free work. Unless you want to track what they’re doing and replicate that, too, but that’s just more evil grunt work.