• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

To dependency or not to dependency, that is the question

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic