# Manifold: compile-time metaprogramming for Java without leaving the compiler

> Manifold is a Java compiler plugin that adds type-safe access to SQL, JSON, GraphQL and other schemas plus language features like extension methods and properties. It works with JDK 8 through 25 and ships IDE support for IntelliJ IDEA and Android Studio.

**manifold-systems/manifold** — Manifold is a Java compiler plugin, its features include Metaprogramming, Properties, Extension Methods, Operator Overloading, Templates, a Preprocessor, and more.

- Repository: https://github.com/manifold-systems/manifold
- Website: http://manifold.systems/
- Stars: 2,760 · Forks: 133
- Language: Java
- License: Apache-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/manifold-systems-manifold

## What Manifold solves, and who ends up using it

Most Java teams that want types for external data end up running a code generator. A schema file goes in, a build step runs, generated classes come out, and the generated directory sits in version control or in a target folder that the IDE has to be told about. Manifold takes the other route. It is a plugin for the Java compiler itself, and it resolves types for SQL, JSON, JSON Schema, YAML, XML, CSV, GraphQL and JavaScript at compile time, inside the same compilation that produces your classes. The README describes the goal as adding language features and type-safe access to external data, APIs and DSLs directly to Java, without leaving the Java compiler and without additional build steps.

The audience is narrower than the feature list suggests. You need a project that builds with a JDK between LTS releases 8 and 25, and you need IntelliJ IDEA or Android Studio, because the README treats IDE support as part of the product rather than a bonus. A team that compiles only through Maven or Gradle on a build server, with editors that are not JetBrains products, gets a different experience from the one the project documents. Manifold is also not a small library you can add to one module and forget. It changes how the compiler resolves symbols across the project, so the decision is closer to adopting a language dialect than adopting a dependency.

## How the compiler plugin resolves types at compile time

Manifold hooks into the Java compiler plugin API. When javac resolves a type it does not find on the classpath, Manifold gets a chance to produce it. That is the mechanism behind the SQL example in the README, where a string literal prefixed with a resource path is turned into a query whose result type is inferred:

```java
Language english =
  "[.sql/]select * from Language where name = 'English'".fetchOne();
```

Nothing in that snippet names a generated class. The plugin reads the schema the resource points at, works out the shape of the result, and the compiler type-checks the assignment. The same pattern covers JSON schema files, where the README shows a builder-style API derived from a User.json file and a request call that posts the object. Because the types are produced during compilation rather than written to disk first, the IDE can answer find-usages for a JSON property directly in Java code, which is the claim the README makes for the JSON module.

The Parts feature is a separate mechanism worth understanding before you adopt anything. It is a compositional model that links independent runtime objects into a composite, and the README's example is a Wizard that links an Actor supplied at runtime. A self-call inside the linked part is dispatched through the composite, so the Hero's takeAction calling attack ends up running the Wizard's attack instead. The README states dispatch is O(1) and equivalent to a conventional virtual call, and points to a formal paper for the model. That is a strong claim, and the paper is where you would check it, not the README.

## Adding Manifold to a Maven build and writing a first type-safe query

The repository is a Maven multi-module project with a top-level pom.xml and an mvnw wrapper, so the build layout is ordinary. The README does not print a copy-paste installation block, so the exact coordinates and the compiler plugin configuration are not reproduced here. What the README does state is the constraint that matters most: JDK LTS releases 8 through 25 and the latest, plus IDE support in IntelliJ IDEA and Android Studio. Treat that range as the first thing to check against your own build.

Once the plugin is active in your build, the smallest useful exercise is a SQL query against an existing database schema. The README gives this shape, where the bracketed path points at the SQL resource and fetchOne returns a single typed row:

```java
Language english =
  "[.sql/]select * from Language where name = 'English'".fetchOne();
```

After that compiles, the reader should be able to open the Language type in the IDE and see fields derived from the schema, and to rename a column in the schema and get a compile error at the call site rather than a runtime failure. That compile error is the whole point of the design. The README also shows writes going through a generated builder and an explicit commit:

```java
Film film = Film.builder("My Movie", english)
  .withDescription("Nice movie")
  .withReleaseYear(2023)
  .build();
MyDatabase.commit();
```

Note the commit call. Manifold does not hide transaction boundaries behind the generated types, which is a deliberate and reasonable choice, but it means the generated layer is a typing layer and not an ORM.

## Where Manifold stops being the right tool

The biggest constraint is the compiler plugin itself. Because Manifold changes type resolution during compilation, every tool that compiles your code has to be aware of it: the IDE, the build, and anything that parses or analyzes sources. The README names IntelliJ IDEA and Android Studio as the supported IDEs and does not name others. If your team edits in a different IDE, or if you have annotation processors, static analysis or code generation steps that assume only standard javac behaviour, that combination is where the friction will appear, and the README does not document a fallback for it.

The second constraint is JDK range. Releases 8 through 25 plus the latest are supported. A project pinned to a JDK outside that window has no documented path. The third is that nothing in the README describes rollback. There is no documented procedure for removing Manifold from a project that has adopted it, and because the feature set includes a preprocessor and operator overloading, code written against those features is not plain Java. The preprocessor in particular changes what the compiler sees before ordinary parsing, so a file that relies on it will not compile without the plugin. That is a real exit cost, and it is the reason to introduce Manifold feature by feature rather than turning everything on at once. The README's own framing supports this: add only the features you want to an existing Java project.

## Manifold compared with code generation tools like jOOQ and annotation processors

The closest comparison in the Java world is a code generator such as jOOQ, which reads a database schema and writes Java source for tables, records and queries. The difference is where the types live. jOOQ produces files you can read, commit and diff; Manifold produces types inside the compiler and writes nothing you can inspect. That trade is the whole argument. Generated source is debuggable, greppable and survives a change of IDE, but it adds a build step, a generated directory, and a regeneration cycle whenever the schema moves. Manifold removes the build step and the directory, and in exchange the types exist only while the compiler is running, which means your tooling has to be Manifold-aware.

Annotation processors sit at a similar distance. They run inside javac and generate source, so they keep the generated files. Manifold's type providers are closer to a compiler extension than to a processor, and the README's claim that there are no code gen steps is what separates the two approaches. For JSON and GraphQL, the practical alternative is usually a hand-written or generated DTO layer plus a mapper, which is more code but has no plugin requirement. None of these alternatives is wrong. The choice comes down to whether your team values a clean build graph more than inspectable generated source.

## Maintenance, upgrades and what the Apache-2.0 licence means here

The repository is not archived, and the last push was on 2026-09-20, which is recent. The README advertises latest v2026.1.4. The project is a multi-module Maven build with a top-level pom.xml, an mvnw wrapper and a settings.xml, so a fork or a local build is a normal Maven exercise. The .circleci and .github directories indicate CI configuration lives in the repository, though the README does not describe the release process or a support window for older versions.

Upgrade cost is tied to the JDK range rather than to the library. Since Manifold supports JDK 8 through 25 plus the latest, a team moving between LTS releases stays inside the documented window, but a team jumping to a JDK the plugin has not been updated for is exposed. The IDE plugin has its own version cadence, and the README does not state how IDE plugin versions map to library versions, so that mapping is something to confirm before an upgrade.

The licence is Apache-2.0, which is a permissive licence with an explicit patent grant. It permits commercial use, modification and redistribution, and it requires that you keep the licence and notice files. The repository includes LICENSE and authors.txt at the top level. This is not legal advice; if you redistribute a modified Manifold or bundle it into a product, have counsel read the NOTICE obligations rather than relying on a summary.

## Conclusion

Adopt Manifold if your team already works in IntelliJ IDEA or Android Studio, ships on a JDK LTS release between 8 and 25, and wants schema types in Java without a code generation step in the build. Skip it if your build runs headless on a plain javac invocation with no IDE in the loop, or if you cannot accept a compiler plugin as a dependency of every developer's toolchain. Before committing, verify three things in your own repository: that your JDK falls inside the stated 8 to 25 range, that every module compiles with the plugin enabled rather than only the modules that use it, and that your IntelliJ IDEA version is one the plugin supports, since the README names IDE support as a first-class requirement rather than an optional extra.

## FAQ

### What JDK versions does the Manifold Java compiler plugin support?

The README states it works with JDK LTS releases 8 through 25 plus the latest. A JDK outside that range has no documented support.

### Do I need IntelliJ IDEA to use Manifold?

The README names comprehensive IDE support in IntelliJ IDEA and Android Studio, and does not name any other IDE. Since Manifold changes type resolution during compilation, the IDE has to be aware of the plugin.

### Does Manifold generate Java source files for JSON or SQL schemas?

No. The README describes compile-time metaprogramming that integrates schemas directly into Java without additional build steps, and the JSON section states there are no code gen steps.

### What is the Manifold Parts feature for?

Parts is a compositional model that combines independent runtime components with internal polymorphism. The README states dispatch is O(1) and equivalent to a conventional virtual call, and links to a formal paper describing the model.

### Can I use only one Manifold feature instead of the whole set?

Yes. The README says to add only the features you want to an existing Java project and keep using ordinary Java, Java libraries and the JVM.

## Sources

- [Issues](https://github.com/manifold-systems/manifold/issues)
- [License: Apache-2.0](https://github.com/manifold-systems/manifold/blob/master/LICENSE)
- [manifold-systems/manifold on GitHub](https://github.com/manifold-systems/manifold)
- [Project website](http://manifold.systems/)
- [README](https://github.com/manifold-systems/manifold/blob/master/README.md)

---

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