Static Analysis to Inspect Third-Party Library Usage

At CQSE, we use Teamscale and static analysis for assessment of technology suitability:

  • Get insights about the relevant third-party libraries used in a codebase.
  • Inspect code patterns corresponding to various third-party libraries.
  • Assess ease of migration away from third-party libraries that are not suitable.
  • Assist with refactoring code and avoid uses of deprecated third-party library.

In this post, I show which are the steps to configure Teamscale for such an assessment. This is illustrated using three open-source projects, FindBugs, Google Error Prone and Microsoft StyleCop. First, I use the Teamscale architecture editor and specify for which third-party libraries monitoring dependencies might be desired. Then, the architecture perspective shows the static analysis results and allows quick inspection of dependencies to third-party libraries.


Example 1: FindBugs

The first step is to configure Teamscale for analyzing the FindBugs source code. One relevant option I enabled for my analysis is to include third-party dependencies in the architecture conformance analysis. (This is shown in a screenshot).

The second step is to create a Java project in Teamscale. I used a Git Remote connector to retrieve the source code from Github ( and a File System connector for the architecture specification file. (In general, one should commit the specification file to the same source code repository. Since I am not a contributor to the FindBugs project, I configured the file system connector and stored the specification file locally.) Also relevant in the configuration are patterns to explicate which files are included/excluded from static analysis. (My project configuration is here) On my laptop, the analysis of this project inspects 113,264 SLOC in less than a minute.

The third step is to add an architecture specification, using the Architecture perspective. Explaining how to specify an architecture using the Teamscale Architecture Editor is beyond the scope of this article. (Refer to my previous article if you intend to use the Teamscale Architecture Editor and are not yet familiar with it.) For the purpose of this article, I grouped sub-components corresponding to the FindBugs source code in the FindBugs component. A second component named Third-Party Libraries groups the various third-party libraries used.


The first outcome is a list of the relevant third-party libraries used:

  • org.apache.bcel: The Byte Code Engineering Library (website)
  • org.apache.commons.lang: Apache Commons Lang (website)
  • org.dom4j: An XML framework for Java (website)
  • org.objectweb.asm: A Bytecode Manipulation and Analysis Framework (website)
  • net.jcip.annotations: An Implementation of JCIP Annotations (website)
  • java.* and javax.*: JavaSE API (website). Note that some packages from the JavaSE API are not modelled in the diagram for brevity.

Next, code patterns corresponding to various third-party libraries can be inspected by clicking in Teamscale on the dependency arrows. Below is a list of dependencies that target the class java.util.Date.


After inspecting the code, it can be observed that some deprecated constructors are used. The API for these functions was not amenable to internationalization and thus was deprecated since JDK 1.1. Dependencies to the other third-party libraries can also be inspected using Teamscale.

Example 2: Google Error Prone

In this case, I used the same analysis profile and a similar configuration for a Java Teamscale project.

After adding an architecture specification, the following third-party libraries can be identified: the Sun Javac Compiler (, the format string checker from FindBugs (findbugs.formatStringChecker), the Checker Framework developed at Washington University, a persistent collections library, the Google Common package (google.common) and the JavaSE API. (My architecture specification can be seen here).

The dependencies on the FindBugs library are listed below:


Example 3: Microsoft StyleCop

For the analysis of the Microsoft StyleCop source code, I used a C# Teamscale project.

After adding an architecture specification (see here for my model), the following third-party libraries can be identified: the JetBrains component corresponds to different namespaces from the ReSharper API (website), code corresponding to the Microsoft.Build provides access to the MSBuild engine, the component Microsoft.VisualStudio corresponds to the Visual Studio Shell namespace.

The static analysis of the StyleCop source code reveals that a few type definitions are placed in the namespace JetBrains, i.e. JetBrains.ProjectModel and JetBrains.ReSharper.Psi even though they corresond to StyleCop code. Otherwise, the sources of all dependencies targetting the ReSharper library are only from the StyleCop.ReSharper namespace as expected.


To summarize, this article listed which are the conceptual steps to configure Teamscale for inspecting third-party libary usage. As examples, I have used three popular static analyzers that are open source. The analysis works equally well for Java and C# codebases and can be used to reveal some interesting third-party library usage patterns.

Let me know via comments how you assess the suitability of third-party library usage in your projects.