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?

Improve this question
8
  • 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
    Commented Jan 31, 2013 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
    Commented Jan 31, 2013 at 18:14
  • 2
    @gnat This question is fine, even in its original form.
    – Thomas Owens ♦
    Commented Jan 31, 2013 at 18:36
  • @ThomasOwens with all due respect, I don't think so; for original version I quickly figured two answers with opposite recommendations, both reasonably justified: welcome polling game
    – gnat
    Commented Jan 31, 2013 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.
    – Thomas Owens ♦
    Commented Jan 31, 2013 at 18:42

2 Answers 2

Reset to default
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.

Improve this answer
8
  • 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 slf4j.org/manual.html#projectDep.
    – Duncan Jones
    Commented Jan 31, 2013 at 18:20
  • I recall some brain-damaging exercises (zillions of excludes 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
    Commented Jan 31, 2013 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
    Commented Jan 31, 2013 at 20:07
  • 1
    +1 for specifying slf4j as provided - very unobtrusive.
    – Gary
    Commented Jan 31, 2013 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
    Commented Jan 31, 2013 at 20:48
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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.