jQuery in Action, 3rd edition
The moose likes Java in General and the fly likes To dependency or not to dependency, that is the question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "To dependency or not to dependency, that is the question" Watch "To dependency or not to dependency, that is the question" New topic

To dependency or not to dependency, that is the question

Bob McLever

Joined: Jan 25, 2013
Posts: 2
I'm refactoring a massive utility library (that I wrote myself) because over the years it has gotten too large with a lot of @Deprecated stuff etc. I am a big fan of interfaces to hide implementation details (and dependencies) so this is pervasive in the rewrite.
Now I'm faced with a connendrum: in the old code I have a few very simple interfaces used for filtering, some of them (unintentionally) very closely match those available in google guava. The question then becomes: do I keep my own interfaces or switch to google guava? The problem with the latter is:

- I use nothing else from google guava so it's a massive dependency to introduce
- I don't want to depend on their goodwill when it comes to keeping the code static
- I focus mostly on writing utilities and frameworks as such I have no use for things like the Predicates class that allows "clean notation" of business logic
- Some stuff in guava should not be used where I work because there are (now) better solutions (e.g. the multicatch stuff). This is however hard to indicate and enforce if you just import the entire guava library.

The advantage of guava is of course: their engineers likely have had much more experience on this subject than me, there might be edge cases that I have not encountered yet and that just work in their library.

So do I:

- keep my own interfaces and in the backend implement stuff with guava? This requires some binding code to translate between the two (I'm leaning heavily towards this solution)
- switch to guava but with the above mentioned downsides

On a sidenote: does anyone know why google combined so many separate utility packages into a single massive library? I kind of like the "many small independent libraries" as opposed to "one giant collection of utilities". But perhaps there is a good reason for this move?
K. Tsang

Joined: Sep 13, 2007
Posts: 3135

Welcome to the Ranch.

Well I personally haven't used or know Google Guava, but from the impression you are saying, it looks like a consolidated Apache Commons API/project. Yet Apache has separated each library into its own jar.

Anyway IMHO keeping the interfaces simple to understand and use is probably what you want. How you implement in the backend is up to you and remember the maintainability issue.

K. Tsang JavaRanch SCJP5 SCJD OCPJP7 OCPWCD5 OCPBCD5 OCPWSD5 OCMJEA5 part 1 part 2/3
I agree. Here's the link: http://aspose.com/file-tools
subject: To dependency or not to dependency, that is the question
It's not a secret anymore!