# Dexmaker: Java code generation for Dalvik bytecode

> Dexmaker is a Java API that emits Dalvik .dex bytecode at compile time or runtime. It is intended for Android code generation and Mockito instrumentation tests, with explicit control over instructions and types.

**linkedin/dexmaker** — A utility for doing compile or runtime code generation targeting Android's Dalvik VM

- Repository: https://github.com/linkedin/dexmaker
- Stars: 1,970 · Forks: 262
- Language: Java
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/linkedin-dexmaker

## Dexmaker's Dalvik-specific code generation model

Dexmaker solves a problem that ordinary Java bytecode libraries do not address directly. It generates Dalvik .dex files rather than Java .class files, which makes it relevant to Android applications, Android instrumentation tests, and tooling that must load generated code on the Dalvik VM. The target audience is primarily Java developers working inside Android projects. The project documentation also positions it as the bytecode layer used by Dexmaker's Mockito integrations.

The API is intentionally close to the Dalvik bytecode specification. Callers declare types and methods, create locals, load constants, select operations, invoke methods, read fields, and emit return instructions. This is a lower-level interface than a source generator or conventional object mapper. It gives the caller direct control over the emitted instruction sequence, but it also places responsibility for type correctness, local variables, calling conventions, and control flow on that caller.

Dexmaker does not require callers to bring an abstract syntax tree, although an application can provide one. In the README's runtime example, the caller defines the shape of a `HelloWorld` class and a `hello` method directly, then writes the operations needed to calculate and print a value. That design is useful when an existing compiler or transformation pipeline already has structured program information. It is less convenient when a developer expects source parsing, naming rules, or automatic class construction from ordinary Java code.

The project also uses Dalvik's `dx` tool as its backend. According to the README, this supplies efficient register allocation and regular or wide instruction selection. That removes some low-level work from the API, but it does not turn Dexmaker into a high-level bytecode abstraction. The caller is still choosing the operations and registering the values that those operations consume.

## Mockito integration for Android instrumentation tests

Dexmaker's `dexmaker-mockito` module provides the bridge needed to use Mockito mocking in Android projects by generating Dalvik bytecode class proxies. The documented Gradle configuration uses the `androidTestImplementation` configuration, which places the dependency in the instrumentation test scope rather than the application's main runtime dependency set:

```gradle
androidTestImplementation 'com.linkedin.dexmaker:dexmaker-mockito:2.28.6'
```

The README states that Mockito is included transitively, so a separate Mockito dependency is not needed alongside `dexmaker-mockito`. Version selection is not entirely independent. The documentation says the Mockito target is recorded in `dexmaker-mockito`'s `build.gradle`, and that the major and minor version of Dexmaker generally matches the major and minor version of Mockito. A team upgrading the dependency should therefore check the module build file rather than assume that any Mockito release will pair with any Dexmaker release.

Dexmaker also includes `dexmaker-mockito-inline` for mocking final classes and methods on Android P or later. The instructions say to use that dependency instead of `dexmaker-mockito`, not both. This limitation is tied to operating-system APIs introduced in Android P. A test suite that must run on older Android versions cannot use this inline path, even if the rest of the Mockito setup is compatible.

For ordinary class proxies, the repository contains a stock code generator at `dexmaker/src/main/java/com/android/dx/stock/ProxyBuilder.java`. The README says this generator is sufficient for AOP or class mocking when the developer does not need to manipulate bytecode directly. That distinction affects adoption. Many Android test teams can start with the proxy module or Mockito integration rather than writing every Dalvik instruction themselves. Dexmaker's low-level API is most relevant when the proxy abstraction cannot express the required behavior.

## Runtime generation with declared types and instruction builders

The runtime example shows the central data flow. A `DexMaker` instance declares a type descriptor, in this case `TypeId.get("LHelloWorld;")`, and assigns it the source marker `"HelloWorld.generated"`. The class is declared with `Modifier.PUBLIC` and a superclass represented by `TypeId.OBJECT`. A method is then declared with `Modifier.STATIC | Modifier.PUBLIC`, and its returned `Code` object acts as the instruction builder.

Locals are declared before instructions are appended. The example reserves three `int` locals, one `String` local, and one `PrintStream` local. It loads constants into `a` and `b`, subtracts `b` from `a` into `c`, calls `Integer.toHexString(c)`, retrieves `System.out`, invokes `PrintStream.println(String)`, and returns. This sequence is a concrete illustration of how Dexmaker maps Java-like operations to Dalvik bytecode without producing a `.class` file.

The final step calls `generateAndLoad` with a parent class loader and an output directory. The README then loads `HelloWorld` through the returned class loader and invokes its `hello` method. In other words, the documented flow is declaration, instruction emission, dex creation, class loading, and invocation in the current process. The README does not document rollback, transaction handling, or a recovery procedure for a partially generated dex file, so applications that expose runtime generation as a long-lived service would need to define their own failure policy.

This API can express more than the README's small example, but the repository does not provide a broad catalogue of control-flow helpers, exception-handling patterns, or compatibility guarantees for every Dalvik instruction. Custom generation should therefore be reviewed against the bytecode specification and the Android versions being supported.

## Installing Dexmaker and generating a first class

For Mockito support, the README gives both Maven and Gradle installation forms. The documented Gradle dependency is the shortest path for an Android project that wants Mockito mocks in instrumentation tests:

```gradle
androidTestImplementation 'com.linkedin.dexmaker:dexmaker-mockito:2.28.6'
```

This adds `dexmaker-mockito` to `androidTest`. The README says that Mockito is included transitively. Projects that need final classes or methods can use the inline module instead, but the README does not provide a separate copyable dependency snippet for that module. Its stated version selection and installation rule should therefore be taken from the module documentation rather than reconstructed here.

The README specifically says not to add both Mockito proxy modules together. The inline path requires a device or emulator running Android P or above because it depends on APIs introduced in that platform version.

For snapshot builds, the README says a new snapshot is published after each merge to the `main` branch. It gives this repository configuration:

```gradle
repositories {
    maven {
        url "https://oss.sonatype.org/content/repositories/snapshots/"
    }
}
```

The latest snapshot version is recorded in `gradle.properties`. The documentation does not give a complete standalone command for running the repository's tests or building a release artifact, so the first real use here is an Android test dependency rather than a documented CLI workflow. Developers using the raw API can follow the README's `HelloWorldMaker` example and place it in an environment capable of compiling Java code and loading the resulting dex file.

## Limitations of low-level generation and proxy alternatives

The main limitation is the amount of code generation detail exposed to the caller. Dexmaker does not accept Java source and does not create Java `.class` files. It expects the developer to model types, methods, locals, and instructions. That is a meaningful constraint for teams that want a declarative builder, automatic overload resolution, or source-level annotations. The README's instruction-by-instruction example demonstrates both the control and the verbosity of this approach.

There is also a platform boundary around final-class and final-method mocking. `dexmaker-mockito-inline` is documented for Android P and above, while `dexmaker-mockito` does not provide that same stated capability. The modules must not be added together. This is not merely a version preference. A single test configuration cannot assume that the inline API will behave on older devices.

A real alternative is `cglib` or `ASM`, both named in the README. Dexmaker differs by targeting Dalvik bytecode and using `dx` as the backend for register allocation and instruction selection. A team already operating entirely in ordinary Java can prefer ASM when `.class` output is what the surrounding toolchain needs. A team working on Android instrumentation or runtime dex generation has a more direct fit in Dexmaker.

The repository does not document rollback, production deployment guidance, or a supported command-line interface. Those omissions matter when considering a generator beyond tests. The README also does not describe performance measurements, so claims about generated-code speed cannot be inferred from this repository.

## Maintenance signals, licensing, and upgrade work

The repository is not marked archived, and the last push was on 2026-05-29. The release history lists version `2.28.6` dated 2025-08-05, `2.28.5` dated 2025-06-16, and `2.28.4` dated 2024-08-09. These dates provide release history, but they do not establish a long-term compatibility policy beyond what the repository documents.

Dexmaker is licensed under Apache-2.0. The repository also contains `NOTICE` and `LICENSE` files. The license permits use and modification under its terms, but this review does not replace review of the license text, notice obligations, or dependencies bundled through the build. Teams should treat the Apache-2.0 grant as the starting point for their own compliance review rather than assume that every transitive package carries the same terms.

Upgrade work appears tied to several project-specific points. The Mockito module build file identifies the targeted Mockito version, and the README says major and minor Dexmaker versions generally follow the corresponding Mockito versions. Android P is required for the inline module. Snapshot users also need to account for builds published after merges to `main`, which can change the artifact they test. The README does not provide a migration guide for upgrading from one Dexmaker release to another, so compatibility of generated instructions and test configurations should be checked in the target Android environment before changing a release dependency.

## Conclusion

Android developers should consider Dexmaker when they need explicit Dalvik bytecode generation or Mockito support in instrumentation tests. It is a poor fit for teams that only need Java .class generation or want a higher-level proxy API. Before adoption, verify the targeted Mockito version, the Android P requirement for final-class mocking, and compatibility of custom instructions with the runtime being tested. The main judgement is specific: Dexmaker is most appropriate when direct control over Dalvik bytecode is part of the requirement.

## FAQ

### What is Dexmaker used for?

Dexmaker is a Java API for compile-time or runtime code generation targeting Android's Dalvik VM. It can generate .dex files, Android class proxies, and Mockito mocks.

### How do I add Dexmaker Mockito support to an Android project?

Add `androidTestImplementation 'com.linkedin.dexmaker:dexmaker-mockito:2.28.6'` to the Gradle configuration. The README says Mockito is included transitively.

### Can Dexmaker mock final classes and methods?

Yes, through `dexmaker-mockito-inline` when the test runs on Android P or later. The README says not to add `dexmaker-mockito-inline` and `dexmaker-mockito` together.

### Does Dexmaker generate Java .class files?

No. The README says Dexmaker creates Dalvik .dex files instead of Java .class files, using Dalvik's `dx` tool as its backend.

### How are unreleased Dexmaker builds obtained?

The README says snapshot builds are published after merges to the `main` branch. It documents adding `https://oss.sonatype.org/content/repositories/snapshots/` as a Gradle Maven repository and checking `gradle.properties` for the latest snapshot version.

## Sources

- [Issues](https://github.com/linkedin/dexmaker/issues)
- [License: Apache-2.0](https://github.com/linkedin/dexmaker/blob/main/LICENSE)
- [linkedin/dexmaker on GitHub](https://github.com/linkedin/dexmaker)
- [README](https://github.com/linkedin/dexmaker/blob/main/README.md)
- [Releases](https://github.com/linkedin/dexmaker/releases)

---

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