Soot: a Java optimization framework in maintenance mode, with a successor

The README opens with its own successor

The first substantive line of the README is a warning label: Soot is now succeeded by SootUp. The project released SootUp in December 2022 as a version of Soot with what the README describes as a completely overhauled architecture, more modular, more testable and more maintainable, and it tells you to start new program-analysis projects there.

The second paragraph is the reason this project still exists, and it is more specific than a generic deprecation notice. SootUp is not yet feature complete, so the old Soot needs to keep living, particularly for projects that require instrumentation capabilities or support for Android. The README states the old Soot is still maintained until a feature complete successor can safely replace it.

That framing changes how you read everything else. Soot is not a project waiting to be revived and not one being abandoned tomorrow. It is a project with a defined end condition, and the two features named as the reason for the delay are the two things to check first against your own requirements.

The README also asks users to report which projects depend on Soot through a wiki page, and names Amazon Web Services as a Gold Sponsor. Both are funding and prioritisation signals rather than technical ones, but they explain why the code still gets attention.

Four intermediate representations and what each is for

Soot's contribution is a set of four representations between raw bytecode and your analysis, and the README describes each one in a sentence, which is enough to understand the design.

Baf is a streamlined form of bytecode, described as simple to manipulate. Jimple is a typed three-address representation, which is the one you will encounter most and the one designed for optimization work. Shimple is an SSA variation of Jimple, so it exists for dataflow analysis where single static assignment is the natural formulation. Grimp is an aggregated version of Jimple suited to decompilation and code inspection, which means the shape a human reads differs from the shape an optimizer wants.

Four representations is more machinery than a tool that only needs one, and it is also what makes Soot a framework rather than a library with a single job. The cost is a learning curve and a larger surface to configure, since a Soot pipeline normally names which representation each stage sees.

For anyone deciding between Soot and a byte-level library such as ASM, the distinction is level of abstraction. A byte-level library exposes instructions. Soot gives you typed three-address code and an SSA form, which is the difference between pattern matching on opcodes and writing an actual dataflow or call graph analysis.

Depending on Soot from Maven, Gradle or SBT

Soot is a release artifact on Maven Central under `org.soot-oss`, and the README gives two coordinate sets depending on which branch you want. For the released version:

<dependencies>
  <dependency>
    <groupId>org.soot-oss</groupId>
    <artifactId>soot</artifactId>
    <version>4.7.0</version>
  </dependency>
</dependencies>

and for a snapshot built from every commit to the develop branch, which also requires adding the Sonatype snapshot repository:

<dependencies>
  <dependency>
    <groupId>org.soot-oss</groupId>
    <artifactId>soot</artifactId>
    <version>4.8.0-SNAPSHOT</version>
  </dependency>
</dependencies>

The documented version is 4.7.0, while the release list shows 4.7.0 on 2026-02-13 and 4.7.1 on 2026-02-23. So the example in the README is one patch behind the current release. Both facts come from the same repository, and the practical reading is that the documentation snippet was not updated after the patch release, so resolve the version from the release list rather than from the README.

If you would rather not manage dependencies at all, the README describes the two jar shapes: `soot-<RELEASE>-jar-with-dependencies.jar` bundles everything, while `soot-<RELEASE>.jar` contains only Soot and lets you pick dependencies yourself. The project's recommendation is the bundled one if you do not want to bother, which is the right default for trying it out.

master carries releases, develop carries work

The README states that Soot follows the git-flow convention, that releases and hotfixes are maintained on `master` and that development happens on `develop`. The repository's default branch is `develop`, and the continuous integration badge in the README is pointed at that branch.

Those three facts together describe a workflow where the branch you land on by default is the unstable one. If you clone the repository and build what you get, you are building 4.8.0-SNAPSHOT territory rather than the 4.7.x line. For a research tool that is exactly what you want, and for anything pinned into a build it is a reason to name a version explicitly.

The tree also tells you what kind of project this is. `doc/` and `tutorial/` hold documentation and worked examples, `eclipse/` and the `.classpath` and `.project` files mean the project is developed in Eclipse, `codingstyle/` and `README.coding_rules` carry contribution conventions, `test-classes-asm/` is a test fixture set for the ASM bytecode library, and `credits` plus `CHANGES` are long-running project records. `pom.xml` at the root confirms Maven, and `.gitpod.yml` means the project is meant to be opened in a browser-based development environment without local setup.

The split between `CHANGES` and a changelog file in newer formats is a small signal of age, consistent with a codebase that predates most current Java build tooling.

Java 9 module support, and where it stops

The README has a dedicated section listing module support as tested and untested, and the untested list is short enough to quote. Working: automatic modules, which are created from jars on the module path, named modules, exploded modules, modular jar files, resolving modules through Soot's `ModuleScene`, and Spark. Not working yet: anonymous modules, described as mixing the module path and the class path, and multi-module jar files.

That is a useful boundary because the two unsupported cases are exactly the ones that appear when a build is not fully modularised. A codebase with mixed paths falls into the anonymous module case, and a jar that bundles several modules falls into the other.

The README also separates two dimensions people conflate: running Soot on a newer Java runtime is straightforward, while analyzing code compiled for a newer Java from an older Soot runtime is the case that needs the extra setup. It covers loading modules into `ModuleScene` from source code, configuring the module path through Soot's `Options` class, and using `ModulePathSourceLocator` to map classes to modules before loading them.

The `ModuleScene` is the piece worth understanding. Soot models the program as a scene of classes, and modules add a level above that. Analysis that crosses module boundaries has to consult it, which is why module support is not only a parsing feature.

Costs, licensing and the honest comparison

The licensing is LGPL 2.1, which is a real consideration for a library that gets linked into analysis tools. LGPL is designed to allow linking without imposing copyleft on the whole of a proprietary product, but the obligations depend on how you distribute and whether you modify it, and that is a question for your own counsel rather than for a README. It is worth settling before you build a tool around Soot, not after.

The operational cost is moderate. The README recommends using Soot with Maven rather than building it yourself, points at a command line build guide for the cases where you must, and asks contributors to read `CONTRIBUTING.md` first. Learning the configuration model is the larger investment, since a Soot pipeline is assembled from options rather than discovered from a single entry point.

The honest comparison is with SootUp and with byte-level libraries. Against SootUp, Soot wins on the features SootUp has not finished, named as instrumentation and Android, and loses on architecture and long-term direction. Against ASM or a similar bytecode library, Soot wins whenever your analysis needs types, control flow or dataflow rather than instruction matching, and loses when you want a small, fast, predictable dependency.

One more thing the project asks for is worth repeating because it says something about the state of things: the README asks users to fill in a form saying who they are and which affiliation, partly so that user numbers can be shown and partly so that improvements can be prioritised. A framework asking its users to self-identify is a project whose continuation depends on visible adoption.

Editorial conclusion

Soot is worth adopting for a new project only if you need what SootUp does not yet have, which the README names as instrumentation capabilities and Android support, or if you already depend on it and cannot afford the migration. For ordinary static analysis of JVM bytecode, SootUp is the direction the maintainers named in December 2022 and has the architecture to match. Concretely, check three things before choosing: whether the features you need are in SootUp yet, whether instrumentation is the requirement that keeps you here, and whether the 4.7.x line is enough given that 4.7.1 shipped on 2026-02-23 while the documented coordinates still say 4.7.0. The LGPL 2.1 licence is a separate question from suitability and is worth settling early if you intend to ship a tool that links Soot.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-2.1
3. README
4. Releases
5. soot-oss/soot on GitHub