Tai-e static analysis for Java and Android

Tai-e's Java Analysis Scope

Tai-e addresses the need to build static analyses without assembling every compiler, call-graph, pointer-analysis, and vulnerability-detection component from scratch. Its intended users are static-analysis developers, security researchers, and engineers who need to inspect Java programs. The framework also targets Android application analysis, with the README stating that Android support is provided through a PacDroid-powered plugin integrated with pointer analysis.

The project is broader than a taint scanner. Its major components include pointer analysis, configurable security analysis, control and data-flow analysis, fundamental analyses, and a SpotBugs-like bug detection system. The README names reflection analysis, exception analysis, lambda and method reference analysis, invokedynamic analysis, live-variable analysis, and constant propagation as examples of included analyses or analysis facilities. This matters when choosing a tool because a single framework can host several analysis tasks, provided the needed capability is actually implemented or configured in the selected release.

Tai-e is written in Java and the README states that it runs on Windows, Linux, and macOS. That makes the platform claim useful for local command-line analysis, but it does not mean that every analysis plugin supports every operating system or every Java input format. The documented scope is Java and Android, not arbitrary bytecode ecosystems.

Pointer Analysis and Call-Graph Construction

The central mechanism described by the README is an extensible pointer-analysis framework. It supports on-the-fly call-graph construction, heap-abstraction techniques, and context-sensitivity techniques. The exact algorithms and configuration options are not reproduced in the repository excerpt, so an adopter should consult the version-specific reference documentation before assuming that a particular precision mode is enabled by default.

Tai-e also provides an analysis plugin system for analyses that interact with pointer analysis. This is the relevant extension point for research workflows. A plugin can be placed inside the analysis process rather than treated only as a separate command that consumes an already completed result. The README describes this as convenient development, but the practical value is architectural: pointer information is available to other analyses within the framework.

The release notes for v0.5.4 add a new frontend for converting Java programs into Tai-e IR. They also identify Android analysis through PacDroid and Spring DI and WEC analysis through a Spring analysis plugin. Those additions show that frontend and domain plugins are part of the framework's design, not just examples placed in a separate repository. They do not, by themselves, document compatibility with every Java release, Android Gradle Plugin version, or Spring application.

Configuring Taint Analysis and Vulnerability Checks

Security analysis is configurable around taint sources, sinks, taint-transfer rules, and sanitizers. That configuration boundary is important. A framework can detect information leakage or injection only if the application-specific definition of untrusted input and dangerous behavior is represented correctly. The README does not provide a complete configuration file or enumerate every detector rule, so it would be unsafe to infer a particular rule name or default policy from this summary.

Tai-e also includes utility facilities such as an analysis timer, constraint checker for debugging, and graph dumpers. These features point toward analysis development and diagnosis rather than only a final pass or fail result. Constraint checking can help inspect whether analysis conditions hold, while graph dumping can make relationships available for debugging. The repository excerpt does not explain the output format, the analysis state at which these tools run, or whether graph files can be consumed by an external viewer.

The framework's security component is therefore best understood as a programmable base. Teams can define which operations introduce taint, how it moves, where it is removed, and which operations count as sinks. That is more flexible than assuming every vulnerability has one fixed detector, but it also moves part of the correctness burden to the analyst.

Standalone CLI and First Analysis Run

The README recommends downloading the distribution ZIP from GitHub Releases for a runnable installation. The ZIP is described as containing Tai-e, runtime dependencies, offline documentation, and startup scripts for Windows, Linux, and macOS. For a source build, Java 17 or higher is required. The documented build command produces a distribution ZIP:

./gradlew distZip

The resulting archive is placed in `tai-e/build/distributions/`. After extraction, the documented help command is:

# on Linux/macOS
./tai-e-<version>/bin/tai-e -h

The Windows equivalent is:

.\tai-e-<version>\bin\tai-e.bat -h

The help output is the first useful checkpoint because the repository excerpt does not show the complete command syntax or a complete first-analysis configuration. The README also documents a legacy all-in-one JAR build:

./gradlew fatJar
java -jar build/tai-e-all-<version>.jar -h

That JAR is retained for compatibility with older releases and scripts. New users should therefore prefer the distribution ZIP when following the current standalone workflow, unless an existing integration specifically requires the legacy artifact.

Maven Integration for Analysis Projects

Tai-e can also be included as a Maven dependency. The README identifies the Maven coordinates through the Maven Central badge and states that Tai-e is designed to be a standalone tool while still allowing inclusion in another project. That distinction matters for architecture. A standalone command is useful for inspecting an application from the outside, whereas dependency integration is useful when an analysis tool is itself a Java application.

The README excerpt does not show the dependency XML, version naming rules, repository configuration, or the Java APIs needed to launch an analysis programmatically. It does list recent releases including `v0.5.4` and `v0.5.2`, plus a `v0.5.5-SNAPSHOT` entry. A project should select a published release rather than assume that a snapshot is appropriate for production automation. The Maven metadata shown in the README is intended to identify the current version, but the exact resolved version must be checked against the repository at build time.

The legacy `fatJar` route is different from Maven integration. One produces a runnable archive containing runtime dependencies; the other makes Tai-e a library dependency. The README does not document a compatibility matrix for those two consumption modes.

Where Tai-e Differs from SpotBugs-Oriented Workflows

SpotBugs is a relevant alternative when the immediate requirement is established bug detection rather than building a new analysis framework. The README explicitly describes Tai-e as having a SpotBugs-like bug detection system, with examples such as a null pointer detector and an incorrect `clone()` detector. Its differentiator is the surrounding infrastructure: configurable taint analysis, pointer-analysis integration, control and data-flow frameworks, and plugins intended to interact with pointer analysis.

Tai-e also supports that category, but it is designed for developers who need to add analyses or connect new logic to the framework's pointer information. The repository excerpt does not claim that Tai-e reproduces every SpotBugs detector, matches SpotBugs defaults, or provides the same report ecosystem. It would therefore be a mistake to choose Tai-e solely because it includes a SpotBugs-like component.

Soot, WALA, and Doop are also cited by the README as classic frameworks whose designs informed Tai-e. The excerpt does not provide a feature-by-feature comparison with those systems, so the defensible difference is architectural positioning: Tai-e combines several analysis components and an extension system in one Java framework.

Maintenance, Licensing, and Upgrade Boundaries

The repository is not archived, and its last push was on 2026-09-19. The release list includes `v0.5.5-SNAPSHOT` on 2026-09-07 and `v0.5.4` on 2026-06-22. These facts indicate recent repository activity, but they do not establish compatibility between releases or guarantee that every plugin follows the same upgrade cycle. The repository also contains `CHANGELOG.md`, release notes, a `gradle` directory, and separate release tests, which are concrete places to inspect when upgrading.

Tai-e is licensed under LGPL-3.0. The repository contains `COPYING` and `COPYING.LESSER`, in addition to the stated license. The LGPL terms can affect how a modified or distributed library is combined and redistributed, so an organization should review the license text and its dependency obligations. This is a licensing boundary, not a conclusion about legal compliance for a particular deployment.

The README does not document a general rollback procedure, migration guide for every plugin, or supported-version matrix. Those are material gaps for production adoption. In particular, users of the Android, Spring, or PacDroid plugins should verify the plugin's availability and compatibility in the exact Tai-e release they intend to pin.

Editorial conclusion

Adopt Tai-e when you need an extensible Java analysis stack, configurable taint rules, or plugin-based pointer analysis, especially for research and Android work. Do not treat it as a drop-in replacement for every SpotBugs-style bug scanner. Verify first that your Java 17 build, target application format, analysis plugins, and configured sources, sinks, and sanitizers match your project; the README does not document rollback or a general upgrade procedure.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. pascal-lab/Tai-e on GitHub
3. Project website
4. README
5. Releases