# SootUp replaces Soot's global Scene with immutable views and lazy loading > SootUp is a from scratch redesign of the Soot static analysis framework that compiles JVM bytecode to Jimple, builds call graphs with pluggable algorithms, runs interprocedural dataflow analysis through the IDE and IFDS framework, and removes the Globals and singleton architecture that made Soot hard to embed. **soot-oss/SootUp** — A new version of Soot with a completely overhauled architecture - Repository: https://github.com/soot-oss/SootUp - Website: https://soot-oss.github.io/SootUp/ - Stars: 832 · Forks: 126 - Language: Java - License: LGPL-2.1 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/soot-oss-sootup ## A rewrite of Soot, not a fork with new features SootUp describes itself as a complete overhaul of the good, old static analysis framework Soot, and the README is clear that this is a redesign rather than an incremental fork. The evidence for that claim is in the improvement list, which reads like a list of the things people complained about in Soot for a decade. The first item is a new improved API without Globals and singletons. In Soot, analysis state is held in global singletons, which is why a single JVM can realistically hold one analysis context at a time and why embedding Soot in a server or in a test suite is painful. Removing that is not a convenience change, it is the thing that makes the rest of the design possible. The second is a fully parallelizable architecture. Without global state, two analyses can run in parallel threads, and separate analyses can be composed without one stomping on the other's context. The rest of the list follows from those two. Lazy loading of classes means used and dependent classes are no longer interleaved when they load. A fail early strategy validates input while objects are constructed and built, so a malformed input is rejected at the point of the mistake rather than at the point where the analysis finally touches it. Full Java 21 bytecode support. Multiple views replace the single static Scene, and the Jimple IR objects and graphs are immutable. The target user is a researcher or a tool builder who needs call graph construction and dataflow analysis over Java bytecode and who has hit the walls of the original Soot architecture. The primary language is Java, the licence is LGPL-2.1, and the default branch is develop, which tells you the project develops on a rolling branch and publishes tagged releases from it. ## Bytecode becomes Jimple, and Jimple can be parsed and written back out The analysis substrate is Jimple, Soot's three-address intermediate representation, and SootUp keeps it as the central IR rather than inventing a new one. The pipeline starts with transforming JVM bytecode, and other inputs, into Jimple. The list of what the library provides is short enough to read as an architecture. It provides ClassHierarchy generation, call graph generation with different algorithms and precisions, interprocedural dataflow analysis with the IDE and IFDS framework enabled by Heros, simple transformations applied when retrieving a method's body through the BodyInterceptor mechanism, and parsing and serialization of the Jimple IR. Two of those entries carry most of the weight for a tool builder. The BodyInterceptor is the extension point for method bodies. Instead of a framework that decides what a method body looks like, SootUp lets you apply transformations when a body is retrieved, which is how you would insert your own analysis steps or modify a body before the rest of the framework sees it. Parsing and serialization of Jimple means the IR is not just an intermediate step inside the process. A Jimple file can be read in and written out, so an analysis can be split across processes or across machines, and a Jimple file can be committed as an artifact. For a long running analysis over a large application, that is the difference between a single job that must succeed in one run and a pipeline with checkpoints. The immutability of the IR objects and graphs is what makes that safe. If a Jimple body cannot be modified in place, then two analyses can share it without interfering, and serializing one is guaranteed to produce something consistent with what the other one saw. ## Call graph algorithms are selectable, and precision is a choice Call graph generation is a first class feature rather than a fixed default, and the README describes it as generation with different algorithms and precisions. That phrasing matters more than it sounds. A call graph is the backbone of most downstream static analysis: reachability, taint tracking, dead code detection and impact analysis all start from it. The classic trade-off is between a cheap, imprecise graph that misses edges and an expensive, precise one that does not scale. Making the algorithm a selectable part of the design means the caller picks the point on that curve for the question at hand, and can change it without rewriting the analysis. The repository layout shows how much lives in this layer. There is a dedicated sootup.callgraph module, plus sootup.spark, sootup.qilin and a sootup.codepropertygraph module. The names correspond to known call graph and graph representation approaches in this space, and the fact that they are separate Maven modules in one repository tells you the project is designed so that a consumer can depend on the graph construction layer without pulling in the whole analysis stack. There is also a sootup.apk.frontend module, which extends the same machinery to Android packages, and the topic list for the repository includes android alongside java, jimple, bytecode and dataflow analysis. For a security tool, the reachability question dominates, and it is the one the README highlights: Team Atlanta, the winner of DARPA's AI Cyber Challenge, uses SootUp to improve their reachability analysis, with a linked paper on that work. Reachability is the hard part of vulnerability detection, because the interesting question is not whether a dangerous function is called somewhere, it is whether a specific path of calls reaches it with attacker controlled data. Building a call graph that a good path analysis can be layered on top of is a different design problem from shipping a scanner, and it is the design this project chose. ## Interprocedural analysis is IDE and IFDS, with Heros doing the work Interprocedural dataflow analysis is enabled through the IDE and IFDS framework, and the README credits Heros as the enabler. Heros is a framework for solving interprocedural dataflow problems efficiently, and it is a substantial piece of the machinery rather than a thin adapter. The distinction between intraprocedural and interprocedural modules in the repository makes the structure explicit. There is a sootup.analysis.intraprocedural module and a separate sootup.analysis.interprocedural one. Intra-procedural analysis handles facts within a single method body, interprocedural analysis propagates them across call boundaries according to a call graph, which is where the call graph choice from the previous section starts to matter. The IDE framework, on which IFDS is built, expresses a dataflow problem as a graph problem with flow and call edges, and solves it with a worklist algorithm. The practical consequence for a user of SootUp is that writing a new analysis means defining the transfer functions and the flow and call relations rather than implementing a solver. That is a large saving for anyone whose real work is the domain logic of an analysis rather than the fixed point iteration. This is the part of the framework where the academic lineage is most visible, and it is also the part most likely to be the reason to choose SootUp over writing something from scratch. The parts where you have to make your own choices, the transfer functions for your analysis, stay yours. ## Views instead of a Scene, and a module layout you can depend on The architectural change with the widest blast radius is the replacement of the single static Scene with multiple views. In Soot, the Scene is the central container of the loaded program: the classes, the call graph, the type hierarchy, the bodies. It is global, and everything reads from it. The consequences are well known to anyone who has used Soot. You get one analysis per JVM in practice, you cannot run two analyses with different configurations side by side, and you cannot easily checkpoint or resume. SootUp's Multiple Views means you can have several independent views over the program, each configured the way that analysis needs. Together with lazy loading, that changes the practical cost model. Lazy loading means you do not have to load the whole transitive closure of a program before you start, which matters for large applications where the closure is enormous and only part of it is relevant to the question being asked. The module layout supports this. The repository is a multi-module Maven build with pom.xml at the root and separate modules for the core, the Java bytecode frontend, the Jimple frontend, the Java core, the call graph construction, the intraprocedural and interprocedural analysis, the interceptors, the report module, the examples, the tests, the Qilin, Spark and code property graph modules, and the APK frontend. The frontend split is the important structural decision. Separating the Java bytecode frontend from the Jimple frontend means the analysis layer does not depend on how the program was obtained. A front end produces views of a program, and the analysis works on those views. That is what makes the APK frontend possible without duplicating the analysis code, and it is why the same analysis code can run over bytecode, over Jimple files, or over anything else a new frontend can produce. ## Documentation, examples and the paper that explains the design Getting started is documented rather than improvised. The README points to the documentation site at soot-oss.github.io/SootUp, to the Javadocs at soot-oss.github.io/SootUp/apidocs, and to a separate SootUp-Examples repository for usage examples. There is a discussions area for questions, and the project asks for issues to carry feedback and feature requests. For an academic project, the most important document is the paper. The README links the SootUp paper published in the Tools and Algorithms for the Construction and Analysis of Systems, and explains that it goes further in describing the design decision behind SootUp. A preprint is also available in the repository at docs/assets/SootUp-paper.pdf. If you are evaluating whether to migrate from Soot, that paper is the place to find the reasoning, because the differences listed in the README are the conclusions and the paper is the argument. The project also asks researchers to cite it, and the README includes the BibTeX entry with the paper title SootUp: A Redesign of the Soot Static Analysis Framework and the author list. A CITATION.cff file at the repository root serves the same purpose for citation tools that read it. Two badges in the README describe the engineering setup. The unit and integration tests run with Maven, and the coverage is reported to codecov for the develop branch, with the codecov badge pointing at that branch. There is an OpenSSF Scorecard badge and an OpenSSF Best Practices badge, which are the signals a security project looks at when deciding whether to depend on a library that parses untrusted bytecode. ## Licence, releases and who is actually shipping this SootUp is licensed LGPL-2.1, with the license text in the LICENSE file at the repository root. For a library that is linked into analysis tools, the LGPL is a workable choice: modifications to the library itself must be published, while applications that merely use it are not forced to open their own code. That is a materially different position from a tool you have to fork, and it is worth understanding before you decide whether to embed SootUp in a commercial security product. The release line has moved quickly. Tagged versions include v2.0.0 from 2025-02-19, v3.0.0 from 2026-07-16 and v3.0.1 from 2026-08-07, and the last push was on 2026-10-19 with the repository not archived. Two major versions in about a year and a half, with a patch release three weeks after the 3.0.0 tag, is the pattern of an API that is still moving. That matters for anyone planning a migration from Soot. The improvement list reads like a promise, but the practical question is which Soot features have SootUp equivalents in which module, and the answer is not uniform. The call graph, analysis and frontend modules exist and are separate artifacts you can depend on individually, but there is no compatibility layer over legacy Soot in the repository. The clearest external signal of quality is the one the README leads with. Team Atlanta used SootUp to improve its reachability analysis and won the DARPA AI Cyber Challenge, and the linked arXiv paper describes that work. That is a public, technical demonstration of the framework on a hard problem rather than a claim in a marketing section. It is also the reason to read the reachability paper alongside the SootUp paper, because the former shows what the framework enabled and the latter explains why it was built that way. ## Conclusion SootUp is the right choice for a research group or a security tool that needs call graph and dataflow analysis over JVM bytecode and has been blocked by Soot's global state, and it is the wrong choice for a rule based linter or a simple dependency scanner, since it is a framework rather than a tool; before adopting it, read the SootUp paper linked from the README and check that your analyses exist in sootup.callgraph and sootup.analysis.interprocedural rather than assuming a Soot feature was carried over. ## FAQ ### What is SootUp and how does it differ from Soot? SootUp is a complete overhaul of the Soot static analysis framework. The README lists a new API without Globals and singletons, a fully parallelizable architecture, lazy class loading, a fail early validation strategy, full Java 21 bytecode support, multiple views instead of one static Scene and immutable Jimple IR objects. ### What can SootUp analyze? SootUp transforms JVM bytecode, and other inputs, into the Jimple intermediate representation, provides ClassHierarchy generation, call graph generation with different algorithms and precisions, interprocedural dataflow analysis with the IDE and IFDS framework enabled by Heros, transformations on method bodies through BodyInterceptor, and parsing and serialization of the Jimple IR. ### How do I start using SootUp? The README points to the documentation at soot-oss.github.io/SootUp, the Javadocs at soot-oss.github.io/SootUp/apidocs, and usage examples in the separate SootUp-Examples repository. The Maven artifact is published to Maven Central under the org.soot-oss group with the artifact name sootup. ### Who uses SootUp in production? The README states that Team Atlanta, the winner of DARPA's AI Cyber Challenge, uses SootUp to improve their reachability analysis, with a linked paper describing that work. Development is financed by support from the German Research Foundation and the Heinz Nixdorf Institute. ### What licence is SootUp released under? SootUp is licensed LGPL-2.1, with the license text in the LICENSE file at the repository root. Releases include v2.0.0 from 2025-02-19, v3.0.0 from 2026-07-16 and v3.0.1 from 2026-08-07, with the last push on 2026-10-19. ## Sources - [License: LGPL-2.1](https://github.com/soot-oss/SootUp/blob/develop/LICENSE) - [Project website](https://soot-oss.github.io/SootUp/) - [README](https://github.com/soot-oss/SootUp/blob/develop/README.md) - [Releases](https://github.com/soot-oss/SootUp/releases) - [soot-oss/SootUp on GitHub](https://github.com/soot-oss/SootUp) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/soot-oss-sootup