views:

225

answers:

7

There's always a balance when deciding whether to use a 3rd party library or write your own code. Writing your own takes time and will incur a maintenance cost. Using the 3rd party library has its downsides too, with the potential for version incompatibilities every time you update the dependencies.

With some libraries, the downsides are really light, and they're brought in as dependencies without much thought. For example, I use a couple of the apache commons libraries pretty much like the java.* packages - I'll pull in commons-lang or -io in just to use a single class. My justification for doing this is that the back compatibility of these libraries has been great so far, so they're unlikely to give me back compatibility problems in the future, and that they're likely to be on the classpath of some other library I'm relying on anyway.

Are there any other libraries that you bring in without worrying that back compatibility issues will hit you in the future?

+4  A: 

The google collections library is very useful library that I have found to be very high quality.

Chi
I've just discovered it. It hasn't seen a full 1.0 release yet, as far as I can see, so isn't it a bit premature to say how they'll deal with back compatibility?
Jim Downing
It's google. I think that's enough information to back it.
Stefan Kendall
+1  A: 

I feel comfortable with pretty much everything from apache. I don't agonize too much over whether its going to be a pain in the future.

Vincent Ramdhanie
+1 for the Commons!
Ben S
Even commons-logging? That's never given you pain in the past?
Jim Downing
Actually never used it directly...are you suggesting that it caused you a problem? If so thanks for the heads up.
Vincent Ramdhanie
Yes, the dynamic logging lookup doesn't always play with with class loaders. The modern equivalent is SLF4J (http://www.slf4j.org/). Personally, I ditched clogging and just went back to using log4j directly.
Jim Downing
I have always used log4j and have never had a reason to switch to commons-logging...though I just checked and I do have it in my locval repository cause I may have considered it in the past.
Vincent Ramdhanie
+6  A: 

Joda Time is a high quality alternative to Java's awful inbuilt Date/Time APIs

alasdairg
+4  A: 

Log4J works very well.

JuanZe
Right now we have some synchronization problems with the actual stable version (1.2.15) of log4j. A lot of threads are using the same `Logger` and produce a deadlock from time to time.
tangens
Have a look at logback http://logback.qos.ch/
Pascal Thivent
+4  A: 

If it's a core business function, do it yourself no matter what.

Coding Horror has a post about it. Scroll down the page to get to the quote. If is referring to a Joel On Software article.

A lot of it will depend on how much support you might need to use the library. If there is a bug, is a workaround ok or do you REALLY need a patch. Do you have the time, skill, or inclination to fix a bug or extend a class and recompile the library while managing the version dependencies?

Kelly French
If you only use OpenSource third party libraries, you can leverage the 95% in there you need and write the last 5% yourself. Do not underestimate the strength of a library others have used for years.
Thorbjørn Ravn Andersen
+4  A: 

The Spring Framework is by far one of the best and most stable libraries I've used.

Adamski
It's not a library, it's a framework :)
Pascal Thivent
+1 for agreeance. It really IS a framework, but it CAN be used as a library. No one says you have to use spring for IoC :P. It offers a bit more than that.
Stefan Kendall
I thought I'd cover all bases by describing it as a framework and a library :-)
Adamski
+2  A: 

Implement a wrapper around 3rd party libraries

If you feel uncomfortable with a 3rd party library, you should consider to write a wrapper around it, that only provides the methods you really need.

This is most important if the library is used almost everywhere in your code. If it's only used in one class, writing a wrapper is useless, of course.

Write Unit Tests

Then write unit tests to verify that the needed functionality works (the way you use it).

tangens
How does this help? What do you do when the library changes and the tests fail? Is the intention that when the pain of maintaining the adapter wrapper gets too great you should implement your interfaces?
Jim Downing
BTW you do not have to always use the last version of a 3rd party lib...
pgras
@Jim: If the library changes, you only have a to adapt a single class to the new version.
tangens