3rd party library criteria and considerations

[errael]

Since this question comes up. Here's some thoughts on the subject.

Some factors when considering a 3rd party library.

1. How widespread is its use, community, mvnrepository.com
2. Release activity
3. Development activity, commits
4. How easy to back it out
5. Important Feature in the artifact

In some cases it is possible to design in 4. This factor is often independent of the artifact and depends on how its usage is integrated into the project.

In all cases, thanks to maven, you select a particular release and it is frozen. If you use an artifact in such a way that you fully test it for use, it does not change.

Five above may be an overriding factor. But clearly if a project is abandoned, who ever uses it must pick up support. In particular, you're on your own.

Here's an arbitrary classification. This ordering is based on how widely the artifact is used. This is out of over 37,000 artifacts. The developer and user community affect the rating. The top 200 are around .5% of all projects. Even artifacts that are not in the top 200 may be useful, in these situations developer and community response could be important. The risk of using an artifact goes up with its complexity.

GOLD - over 2,500 usages, top 30
SILVER - over 1,000 usages, top 80
BRONZE - over 325 usages, top 200

The usage information at mvnrepository.com shows the usage of an artifact in other maven projects and how often it's released. Looking at a projects commit log and issue tracking provides more information.

Here's the breakdown for some artifacts under consideration

• google-guava

  • 25,747 usages
  • 3-4/year releases
  • very active
  • used internally in google
  • 2nd overall (1st is junit)

• org-openide-util-lookup

  • 1,259 usages
  • 4/year releases
  • very active
  • key component/concept of top shelf IDE
  • this is a small part of a huge, and widely distributed, app; the usages doesn't reflect how widespread this artifact is

• metrics-core

  • 1,772 usages
  • 6+/year releases
  • very active, good looking issue handling
  • many "reporter" plugins

• java-getopt

  • 73 usages
  • only 1 release ever, in 2010
  • This may be the exception that proves the rule. It is possible for something to be stable and finished. Rare, but possible.

[bpangburn]

Great info. Definitely a good way to make informed decisions.

You left our GlazedLists, which appears to have 6 usages.

[errael]

• glazedlists
  • 6 usages
  • 3 years since release, v1.11.0 January 2018, almost a year before that v1.10.0 March 2017
  • last snapshot April 2019 v1.12.0-SNAPSHOT
  • last commit June 2020
  • looked through the 26 forks, no activity

glazedlists seems to have been abruptly abandoned int the middle of 2020.

Since v1.10, looks like some bug fixes, shift to gradle, using more modern jdk. Last development was SeparatorLists, which javadoc says is subject to change and under heavy delevopment and performance not suitable for lists over ~100.

[bpangburn]

Two other considerations are (a) cascading dependencies and (2) security.

Tools like Maven make it easy to deal with a library which itself may have many other dependencies, but it's good to at least consider that apps may manage dependencies other ways and it's good to keep cascading dependencies to a minimum. Compile and runtime dependencies can be different.

Security is another concern (and it's compounded by cascading dependencies). Many organizations monitor updates/changes for vulnerabilities at the library level. There are tools like dependency-check-maven (from owasp.org), which will scan your applications and alert you if there are vulnerabilities in an app/dependency. internal/external IT staff and internal/external auditors will often run tools like this against an entire network, and the goal is to keep detected vulnerabilities to a minimum. Even though the vulnerable part of a library might not be in use or it might be used in an environment that is not exposed, exceptions become very hard to document/justify/maintain so it's best to keep them to a minimum.