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?
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.