13

I've just released a small Java library that offers only a few classes and methods. Since I built the project with Maven, I immediately used several third-party libraries to achieve my goals, specifically:

  • commons-lang3 (for some general Java stuff)
  • slf4j-api (for logging)
  • commons-io (for a tiny bit of file stuff - literally reading a file once, I think)

I don't want my library to appear bloated in the eyes of others. Should I be trying to remove my reliance on these libraries to minimise my footprint? Any advice on what types of libraries would be best to avoid when considering using more in the future?

Duncan Jones
  • 1,392
  • 1
  • 10
  • 18
  • 1
    concrete part of your question looks answerable: your project plus concrete libs plus whether it's OK. The problem is, you spelled it along with general part "should... small... avoid". As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved, see the **[FAQ]** for guidance. – gnat Jan 31 '13 at 17:57
  • 1
    @gnat My apologies. As a regular Stack Overflow user, I had tended to assume slightly subjective questions were acceptable on Programmers. Is there a Stack Exchange site where such issues are OK? In the meantime, I'll remove any vagueness from my question. – Duncan Jones Jan 31 '13 at 18:14
  • 2
    @gnat This question is fine, even in its original form. – Thomas Owens Jan 31 '13 at 18:36
  • @ThomasOwens with all due respect, I don't think so; for [original version](http://programmers.stackexchange.com/revisions/185451/1) I quickly figured two answers with opposite recommendations, both reasonably justified: welcome polling game – gnat Jan 31 '13 at 18:39
  • 1
    @gnat Only two? That's fine. Let them be posted and voted on. Two potentially correct answers with justification and reasoning that are opposite doesn't make the question bad. Neither does 3 or 4 or even 5. It's a well formed question that's a problem library developers must deal with, and the burden is then put on the answers to [be good answers](http://programmers.stackexchange.com/questions/how-to-answer). – Thomas Owens Jan 31 '13 at 18:42
  • @ThomasOwens well _only two_ is that came to my mind immediately, I didn't promise there won't be more. As for justification and reasoning, I really fail to see how this would save it from [Gorilla vs Shark](http://blog.stackoverflow.com/2011/08/gorilla-vs-shark/) issue when question "It’s not nearly specific enough". Paraphrasing the SE blog, _when the library is considered "small", are 3 dependencies small, are 10 small? How strong is "should", avoid at any cost, avoid when deemed reasonable?_ – gnat Jan 31 '13 at 18:57
  • Are we agreed, at least, that it's OK now? – Duncan Jones Jan 31 '13 at 20:10
  • @DuncanJones yes, to me it looks OK now (btw I think your edit was pretty good: subtle but efficient) – gnat Jan 31 '13 at 21:17

2 Answers2

8

I'm answering this considering your specific situation. I would say it's fine to use those libraries. Just make sure your slf4j-api doesn't bring along the implementation with it. By that, I mean mark the implementation dependency as "test". EG:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.7.2</version>
    <scope>test</scope>
</dependency>

This is described in detail on the SLF4j FAQ.

As for the other two, IME, they're always backwards compatible. Therefore, if 5 years from now I need to use your library but you're using an old version of those, I can just exclude your dependencies and our code will still work. In other words, by using these specific libraries you won't introduce jar-hell for others.

If I use your library via maven, I won't notice if your library is bloated or not. I'll just depend on yours and use it. I think it's more important that your code works correctly than its got a smaller footprint. I prefer you use commons-io instead of reinventing the wheel with a bug in it.

Duncan Jones
  • 1,392
  • 1
  • 10
  • 18
Daniel Kaplan
  • 6,776
  • 5
  • 32
  • 46
  • Thank you for the response, I think we broadly agree on the approach I should take. Just to correct one bit - the way one should include slf4j in a library project is to simply include `slf4j-api` and no other related artifacts, provided or otherwise. See http://www.slf4j.org/manual.html#projectDep. – Duncan Jones Jan 31 '13 at 18:20
  • I recall some brain-damaging exercises (zillions of `exclude`s iirc) I had to make when particular modules in my dependencies couldn't "agree" on a slf4j version. From your answer it looks like if module designers would expose it as `provided`, there wouldn't be issues like that, correct? – gnat Jan 31 '13 at 18:26
  • 2
    @gnat Normally that would be solved (in Maven at least), by declaring one preferred version in your POM. Maven takes the "nearest" version defined for an artifact and the immediate POM outweighs transitive dependencies. Possibly this was a behavioural change during a Maven 2.x release. – Duncan Jones Jan 31 '13 at 20:07
  • 1
    +1 for specifying slf4j as `provided` - very unobtrusive. – Gary Jan 31 '13 at 20:32
  • @DuncanJones thanks, I probably missed this back then. My maven version was 2.2 or 2.3, can't recall which one (though I sure remember how `mvn dependency:analyze` was bringing crap versions until excluded:) – gnat Jan 31 '13 at 20:48
  • @DuncanJones If you don't include them provided or otherwise, how do you see logging when your testing your library? For example, a test throws an unexpected exception and you log it. You won't see the stack trace and cause unless you include the implementation – Daniel Kaplan Jan 31 '13 at 22:36
  • @DuncanJones Check out my edit with the link – Daniel Kaplan Jan 31 '13 at 22:54
  • You merely need to add your preferred logging implementation with `test`. Actually... having just clicked on your link, that's what it suggests! Anyway, I'll accept your answer as it seems to have the consensus of the group of users who've found this question. Thanks :-) – Duncan Jones Feb 01 '13 at 06:35
1

No.

"Bloat" is a myth. No matter how much code is in your library, if some of that code is never used it won't be paged in - it will have no impact whatsoever on either performance or memory footprint.

On the other hand, if you need that extra piece of functionality you have two choices. You can either write it yourself and spend a lot of time and effort solving problems that others have already solved before, or you can choose to use the solution that already exists (and has been tested/debugged/etc).

That leaves us with download size and disk space footprint, and unless you're talking silly numbers, in 2013 they're two factors that should be close to the bottom of the list of things you need to worry about.

Maximus Minimus
  • 1,498
  • 10
  • 11