Should you wrap 3rd party libraries that you adopt into your project? [closed]

A discussion I had with a colleague today.

He claims whenever you use a 3rd party library, you should always write for it a wrapper. So you can always change things later and accomodate things for your specific use.

I disagree with the word always, the discussion arose regarding log4j and I claimed that log4j has well tested and time proven API and implementation, and everything thinkable can be configured a posteriori and there is nothing you should wrap. Even if you wanted to wrap there are proven wrappers like commons-logging and log5j.

Another example that we touched in our discussion is Hibernate. I claimed that it has a very big API to be wrapped. Furthermore it has a layered API which lets you tweak its inside if you so need. My friend claimed that he still believes it should be wrapped but he didn't do it because of the size of the API (this co-worker is much veteran than me in our current project).

I claimed this, and that wrapping should be done in specific cases:

• you are not sure how the library will fit your needs
• you will only use a small portion of a libary (in which case you may only expose a part of its API).
• you are not sure of the quality of the library's API or implementation.

I also maintained that sometimes you can wrap your code instead of the library. For example, puting your database related code in a DAO layer, instead of preemptively wrapping all of hibernate.

Well, in the end this is not really a question, but your insights, experiences and opinions are highly appreciated.

Solution 1:

It's a perfect example for YAGNI:

• it is more work
• it inflates your project
• it may complicate your design
• it has no immediate benefit
• the scenarion you write it for may never manifest
• when it does, your wrapper most likely needs to be re-written completely because it is tied too closely to the concrete library you were using and the new one's API simply doesn't match yours.

Solution 2:

Well, the obvious benefit is for switching technologies. If you have a library that becomes deprecated, and you want to switch, you may end up rewriting a lot of code to accommodate the change, whereas if it were wrapped, you'd have an easier time writing a new wrapper for the new lib, than changing all your code.

On the other hand, it would mean that you have to write a wrapper for every trivial library that you include, which is probably an unacceptable amount of overhead.

My industry is all about speed, so the only time I'd be able to justify writing a wrapper is if it was around some critical library that was likely to change dramatically on a regular basis. Or, more commonly, if I need to take a new library and shoehorn it into old code, which is an unfortunate reality.

It's definitely not an "always" situation. It's something that may be desirable. But the time isn't always going to be there, and, in the end, if writing a wrapper takes hours and the long term code library changes are going to be few, and trivial...Why bother?

Solution 3:

The problem here is partially the word 'wrapper', partially a false dichotomy, and partially a false distinction between the JDK and everything else.

The word 'wrapper'

Wrapping all of Hibernate, as you say, is a completely impractical enterprise.

Restricting the Hibernate dependencies to an identified, controlled, set of source files, on the other hand, may well be practical and achieve the same results.

The false dichotomy

The false dichotomy is the failure to recognize a third option: standards. If you use, say, JPA annotations, you can swap Hibernate for other things. If you are writing a web service and use JAX-WS annotations and JAX-B, you can swap between the JDK, CXF, Glassfish, or whatever.

The false distinction

Sure, the JDK changes slowly and is unlikely to die. But major open source packages also change slowly and are unlikely to die. Untold thousands of developers and projects use Hibernate. There's really no more risk of Hibernate disappearing or making radical incompatible API changes than there is of Java itself.

Solution 4:

No. Java architects/wanna-bees are too busy designing against imaginary changes.

With modern IDE, it's a piece of cake when you do need change. Until then, keep it simple.