# WALA: static analysis for Java bytecode and JavaScript, built at IBM and given away

> The T. J. Watson Libraries for Analysis provide a framework for static analysis of Java bytecode and JavaScript, including type and class hierarchy analysis, interprocedural dataflow with the Reps-style solver, a context-sensitive tabulation-based slicer, and pointer analysis with call graph construction. It was developed inside IBM's DOMO research project, donated to the community in 2006, and is now built with Gradle for Java 17.

**wala/WALA** — T.J. Watson Libraries for Analysis, with front ends for Java, Android, and JavaScript, and many common static program analyses.

- Repository: https://github.com/wala/WALA
- Website: http://github.com/wala/WALA
- Stars: 880 · Forks: 244
- Language: Java
- License: EPL-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/wala-wala

## What WALA is: an analysis framework, not a finished tool

The T. J. Watson Libraries for Analysis provide static analysis capabilities for Java bytecode and related languages and for JavaScript. The library is a framework rather than an end-user scanner, and the feature list makes that clear.

What it covers is the hard middle of program analysis: Java type system and class hierarchy analysis, a source language framework supporting Java and JavaScript, interprocedural dataflow analysis using the Reps-style solver, a context-sensitive tabulation-based slicer, pointer analysis and call graph construction, an SSA-based register-transfer language intermediate representation, a general framework for iterative dataflow, general analysis utilities and data structures, and a bytecode instrumentation library called Shrike.

Read as a list, that is the standard stack of a serious static analyser. The type hierarchy answers what is a subtype of what. The pointer analysis and call graph answer who can call whom. The dataflow solver propagates facts across the program. The slicer uses the call graph and the dataflow to compute the statements that could affect a given value. The SSA register-transfer IR is the substrate all of that runs on.

For users, the entry point is the Maven Central packages, and the README says that is the fastest way to get started. A separate WALA-start repository gives a Gradle-based example, and tutorial slides are provided for both Core WALA and WALA JavaScript.

## The lineage: DOMO at IBM, then a donation to the community

The history in the README explains a lot about how the codebase is put together.

The initial WALA infrastructure was independently developed as part of the DOMO research project at the IBM T. J. Watson Research Center. In 2006, IBM donated the software to the community. That is a twenty-year-old codebase that started as research infrastructure, and the consequences are visible in the structure: there is a build-logic/ directory, an ide/ directory, a run-time-trials/ directory and a summarize-time-trials/ entry at the top level, alongside the core modules.

The licence is the Eclipse Public License, and the README states that it has been approved by the OSI as a fully certified open source licence. EPL-2.0 is a file-level copyleft licence, which is a reasonable fit for a library where you want improvements to flow back but do not want a whole application to be forced open source.

The front ends are split across languages. Java and JavaScript are supported by the source language framework, and the Android bytecode front end appears in the tree as dalvik/. The repository also contains scandroid/, and the module named cast/ suggests a cast analysis component. The description mentions front ends for Java, Android and JavaScript, which matches the module layout.

Two directories are unusual enough to be worth naming. code-coverage-report/ and aggregated-javadoc/ are build outputs that live in the tree, and generate-latest-docs.sh is the script that refreshes the published documentation.

## Getting started: Maven packages, a Gradle example and the wiki

The README's practical advice is short. Use the packages in Maven Central, and look at the WALA-start repository for a Gradle-based example. There is no install script and no distribution archive to unpack, because WALA is consumed as a library.

The build system is Gradle, and the README points to a separate Gradle-specific README for instructions and tips if you intend to modify or build WALA yourself. The tree confirms the Gradle setup, with build.gradle.kts and settings.gradle.kts at the top level, a gradle/ directory, the gradlew and gradlew.bat wrappers, and build-logic/ for convention plugins. The Java version is pinned in foojay-resolver-convention-version.txt, which is the Gradle toolchain resolver setting that lets the build select a matching JDK.

Each official WALA release is built for use with Java 17 or newer. That is a floor worth planning around, because the analysis operates on bytecode and the class file format has moved several times since 2006.

The documentation story is honest about its own messiness. The README says the team is actively reorganising the deeper wiki technical documentation, and that in the meantime you can use tutorial slides for an overview: a Core WALA tutorial PDF and a WALA JavaScript tutorial PDF, plus screencasts of the JavaScript tutorial on YouTube.

Searching the wiki is a workaround the README recommends, using a site-specific search on GitHub for a term such as call graph, because the wiki is a set of pages rather than a single indexed document.

## The documentation model: a wiki maintained by demand

The README is unusually explicit about why the documentation lives where it does. The documentation is hosted on the GitHub wiki, and the stated reason is that they have chosen a wiki format just so that you can contribute. The tone of the invitation is deliberately casual, and it points at a real property of the project: the wiki is edited by people answering questions, not by a documentation team working from a plan.

The publications department behind that work is described as populating the wiki with technical documentation on a demand-driven basis, driven by questions posted to the mailing list and to Gitter. The practical consequence for a reader is that coverage is uneven. A topic somebody has asked about is likely to be documented well, and a topic nobody has asked about may be thin or missing.

For JavaDoc, the situation is different and better: it is hosted at wala.github.io/javadoc and is being updated continuously. The README asks that if a particular file deserves better javadoc, you open a feature request, which is a reasonable way to route doc gaps into a tracker.

For staying current, the README points to the mailing list hosted on SourceForge, and the older Google Group is recommended for searching mailing list archives. So the channel for questions is a SourceForge mailman and Gitter, while the archive search is a Google Group. That is an unusual mix for a project with commits from October 2026, and it reflects how the community has aged.

The README also links a page listing WALA-based tools built by other groups, which is the closest thing the project has to an ecosystem index.

## The JavaScript side: a separate normalizer and two delta debuggers

A large part of the recent work has gone into the JavaScript front end, and the README describes it as expanding the set of WALA tools implemented in JavaScript.

Three separate repositories carry that work. JS_WALA holds a normalizer and some basic program analyses for JavaScript. jsdelta is a delta debugger for JavaScript-processing tools, and WALA Delta is another. The README asks you to see the linked repositories for further details.

The presence of two delta debuggers alongside the core library is worth understanding, because it says something about the state of the JavaScript toolchain. A delta debugger is for a specific situation: a test fails on a large input, and you want to shrink that input to the smallest case that still fails. In the JavaScript world, that means reducing a script to a minimal reproduction. Having both a normalizer, which turns JavaScript into a form the analyser can consume, and delta debuggers, which minimise failing cases, is the tooling you need to make an analyser usable on a real codebase rather than on toy inputs.

It also explains why the JavaScript work sits outside the main repository. The core WALA tree is Java, built with Gradle, and the JS front end is developed in its own repositories with its own build, presumably to keep the two toolchains separate. The tree does contain a requirements.txt at the top level with black, numpy and pandas pinned, which are the Python tooling dependencies for the JavaScript-side experiment scripts rather than for the Java library itself:

```text
black == 26.3.*
numpy == 2.3.*
pandas == 2.3.*
```

The Android bytecode front end, dalvik/, is the other non-Java addition and lets WALA reason about Android applications.

## Limits: research heritage, an uneven wiki and a wide surface area

Three practical limits are worth naming before you plan around this library.

The first is the research heritage. WALA began as research infrastructure inside a project at IBM's research centre and has been maintained by its contributors and users since 2006. That history shows in the module count, in the number of front ends and analyses, and in the fact that the documentation is a wiki maintained by demand rather than a manual written by a team with a schedule. There is no single entry point that does the obvious thing for you, and the tutorial slides exist because reading the wiki front to back is not a reasonable way to learn a system of this size.

The second is the uneven documentation coverage. Some analyses are well documented because somebody needed them recently, and others are documented only by their javadoc. When you are evaluating this for a specific analysis, budget time for reading source, and note that the deeper wiki is being reorganised right now, so a page you bookmark may move.

The third is the size of the surface you inherit. The tree contains core/, dalvik/, cast/, shrike/, util/, ide/, scandroid/ and the trial infrastructure, and there are separate repositories for the JavaScript tooling on top. Getting a build working means resolving the Gradle conventions, the toolchain and the Java version together. For a research group this is normal. For a small product team looking for one call graph, it is a lot of machinery.

There is also a practical detail worth knowing: the README thanks YourKit for providing WALA developers with a licence for their Java profiler, which is used to improve and maintain WALA performance. If you contribute, you can expect the maintainers to profile rather than guess, which is a good sign about how the project is run.

## WALA against a bytecode library and against a JVM-independent analyser

The comparison worth making is not with another static analyser but with the two ends of the same spectrum.

The first alternative is a bytecode manipulation library such as ASM or Javassist. Those give you the instruction stream and let you read and rewrite classes, and they are small, focused and stable. What they do not give you is semantics. A library can tell you that a method calls another method, but it cannot tell you which receiver is used at a call site, so it cannot build a call graph that distinguishes a virtual dispatch from a direct call. WALA sits above that layer: it consumes the class files and produces the type hierarchy, the pointer analysis and the call graph, which are the inputs every serious analysis needs.

The second alternative is an analyser built for a single language and its own tooling, for instance a JavaScript-specific analyser or a native binary analysis platform. Here the difference is scope. WALA's value is that the same call graph construction, dataflow framework and slicer can be applied across Java bytecode, Android bytecode and JavaScript, so a tool that supports several languages shares one analysis core rather than maintaining three. The JavaScript work in JS_WALA, with its normalizer and delta debuggers, is an attempt to bring the JavaScript ecosystem up to a comparable level.

The trade-off is the same in both comparisons and it is worth being blunt about. You are choosing a large, research-derived framework with an unevenly documented API over either a small library that does less or a purpose-built tool that does one thing well. If you need a call graph for one language and a handful of queries, the purpose-built tool will get you to an answer in an afternoon. If you need a slice, a custom dataflow analysis, or the same machinery over several languages, WALA is the option that gives you the pieces to build it.

## Conclusion

Adopt WALA when you are building an analysis tool that needs a real type system, a call graph and a slicer rather than a text-level approximation, and you are willing to work with a large research-grade codebase rather than a finished product. Do not expect packaged tooling, a stable API or documentation beyond the wiki, since the deeper documentation is being reorganised and the wiki is maintained on a demand-driven basis. Verify first that your analysis targets Java 17 bytecode or newer, that the front end for your language is the one you need, and that you have read the release notes for the version you pin, because the release line moves through several patch numbers in a year.

## FAQ

### What analyses does WALA provide for Java and JavaScript?

The README lists Java type system and class hierarchy analysis, a source language framework for Java and JavaScript, interprocedural dataflow analysis with the Reps-style solver, a context-sensitive tabulation-based slicer, pointer analysis and call graph construction, an SSA-based register-transfer language IR, a general iterative dataflow framework, and the Shrike bytecode instrumentation library.

### How do I get started with WALA?

The fastest route is the packages on Maven Central, with a Gradle-based example in the separate WALA-start repository. Each official release is built for use with Java 17 or newer, and WALA itself is built with Gradle using the bundled wrapper scripts.

### Which tools are available for WALA JavaScript?

The README says the set of JavaScript tools has been expanding, and points to the JS_WALA repository for a normalizer and basic JavaScript analyses, plus two delta debuggers for JavaScript-processing tools, jsdelta and WALA Delta.

## Sources

- [License: EPL-2.0](https://github.com/wala/WALA/blob/master/LICENSE)
- [Project website](http://github.com/wala/WALA)
- [README](https://github.com/wala/WALA/blob/master/README.md)
- [Releases](https://github.com/wala/WALA/releases)
- [wala/WALA on GitHub](https://github.com/wala/WALA)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wala-wala