Frederic Barachant's Blog

On the reuse side of things

Swash already had part of its code split to a seperate project, one with a pretty infamous name: preciseInternalDate.

Swash will see an other split: splines!

While i was finishing the splines part of swash, i said to myself that this could easily be extracted to an external package that could be useful to other projects than swash. In fact, i have other projects that would benefit from it, so even within my own projects that would be fine.
Then i thought of other parts that could be useful and could be extracted. But as i was thinking deeper on what could be externalized and reused i wondered about the burden of reuse.

How much does it burden to be smart and fancy? When is it wrong to do it right?

I mean, i -more than once- grumbled over the fact that i needed activation.jar to use javaMail. What if to use one API you suddenly need to add six or eight jars? Swash actually has two jars, soon three. We are all taught the wonderful advantages of object orientation like ease of reuse, but even if not pushed to an extreme, i see it as a burden. Is it acceptable? I don't know.

Next thing i could export to an external lib is interpolation, but as i will soon support java3D canvases within my rendering pipeline, its jars will become somewhat a dependency of swash. (but no, i certainly do not intend to see everyone forced to install java3D. Not having it will simply not render that part of the graph). Only those two things add at least 4 jars (and native libs for java3d)
Supporting inclusion of svg will also add its own pack of jars.

Sure, JSR-277 could solve the problem and make it transparent for developers to include anything but it's not there. And until it is really everywhere and used by everyone -which imho means years- there will be a "legacy mode" to support.

On an other hand, having no real central repository and no real way to handle dependencies makes it a harder decision to whether i should include the whole bang or handle their inexistence gracefully.
Solution number two might turn in a coding nightmare, while solution number one will certainly add unwanted burden to swash.

Bubonic plague or cholera?
What could be the jar count to choose between one or the other?

Comments

• If you have access to all the source code there is nothing stopping you from building your own jar with everything you require in it. In fact I've experimented with unzipping a large numbers of jars and re-jarring them all together. This would be akin to "static linking" in other languages. The pro is one jar. The con is that you cant upgrade individual parts.

  Posted by: aberrant on February 12, 2008 at 10:53 AM

• Sure, it helps in having a single jar.
  But that means that if there are different versions of a library within the classpath, there can be conflicts and cahotic behavior that could be pretty hard to diagnose. This is a second and greater con in my mind.

  Posted by: pepe on February 12, 2008 at 10:27 PM

• This is why I use Maven for now. An application I built yesterday now has 31 Jars attached to it. I even laughed for a second because one of them is ant, which I know I don't use directly. I know why it is included, its because I depend on Groovy, which has at least 1 call to something in Ant, which is why the groovy developers added it to their dependency list. But why would I want to remove Ant from my build? I don't. I don't want to make any assumptions about what Groovy does that needs ant. I'm just about 99% sure my application won't go into the Ant code, but its not my job to care about that. What I'm saying is, I don't care what depends on what anymore, because something else takes care of that for me.

  Posted by: coding on February 13, 2008 at 01:50 PM

This work is licensed under a Creative Commons License.