typescript-generator: TypeScript definitions generated from Java JSON classes

The generated interface mirrors the Java class, field for field

The README gives a Java class with a String name, an int age, a boolean hasChildren, a List of String tags and a Map of String to String emails, and shows the TypeScript output it produces.

public class Person {
    public String name;
    public int age;
    public boolean hasChildren;
    public List<String> tags;
    public Map<String, String> emails;
}

The result is an interface with name, age, hasChildren, tags and emails, where the primitives map to string, number and boolean, the list becomes string[] and the map becomes an index signature. The point of the tool is stated in the description, that if you have a REST service written in Java, or another JVM language, using object to JSON mapping you can use typescript-generator to generate TypeScript interfaces from Java classes. The supported types are listed: all Java primitive types with their corresponding wrappers, String, Date, enums, arrays, List and Map including derived interfaces and implementation classes, and customized type mapping.

It works on compiled classes, not on source

There is a note that changes how you should read the whole tool. typescript-generator works with compiled classes using Java reflection, and it does not use source files, except for the Javadoc feature. In the Maven plugin that means either classes compiled from source files in the same module, or classes added using a dependency element. The practical consequence is that the generator sees the same bytecode your server runs, so what it emits matches runtime behaviour rather than what a human reads in the source, and a class compiled with different generics or with erased type information will produce a different interface than you might expect. It also means the generation step has to run after compilation, which is why the Maven example binds the goal to the process-classes phase.

Maven, Gradle and a direct API, with matching configuration

The tool ships as several modules, and the repository root shows typescript-generator-core, typescript-generator-maven-plugin, typescript-generator-gradle-plugin and typescript-generator-spring. The Maven usage binds the generate goal to the process-classes phase, and the configuration names the JSON library, the classes to process and the output kind.

<plugin>
    <groupId>cz.habarta.typescript-generator</groupId>
    <artifactId>typescript-generator-maven-plugin</artifactId>
    <version>x.y.z</version>
    <executions>
        <execution>
            <id>generate</id>
            <goals>
                <goal>generate</goal>
            </goals>
            <phase>process-classes</phase>
        </execution>
    </executions>
    <configuration>
        <jsonLibrary>jackson3</jsonLibrary>
        <classes>
            <class>cz.habarta.typescript.generator.Person</class>
        </classes>
        <outputKind>module</outputKind>
    </configuration>
</plugin>

The Gradle plugin is applied by id, configured in a generateTypeScript block, and can be run on demand with gradle generateTypeScript or wired into another task by adding a dependency on it. The Kotlin Gradle DSL variant is shown too. If you use neither build system, the README says you can invoke the generator directly through the TypeScriptGenerator.generateTypeScript() method.

Input selection decides how much of your API you get

Input classes are specified with several parameters and they can be combined. The classes parameter takes fully qualified class names and includes all listed classes and their dependencies, with the dollar character used for nested classes such as com.example.ClassName$NestedClassName. The classPatterns parameter takes glob patterns like com.example.*Json, with the star and double star wildcards supported. The JAX-RS options are the interesting ones for a REST service, since classesFromJaxrsApplication takes the fully qualified name of the application class and includes all classes used by the application resources, which the README recommends if you have one, while classesFromAutomaticJaxrsApplication set to true includes classes from automatically discovered REST resources, which it recommends if you have an application without an Application subclass. The excludeClasses list maps the excluded classes to the TypeScript any type.

Output is either a declaration file or an implementation file

The output is configured by three parameters. The outputKind is required and determines whether and how a module is generated, with the values global, module and ambientModule, which is what decides whether the generated interfaces are wrapped in a namespace or exported as a script. The outputFileType selects the TypeScript file type, either declarationFile for a .d.ts or implementationFile for a .ts, and the outputFile gives the path and name. That distinction is worth understanding, because a .d.ts file is consumed by the TypeScript compiler and never shipped, while an implementation file is compiled into your bundle. The README links the Modules and Namespaces page for the detail, and the presence of a typescript-generator-spring module plus sample-maven-spring and sample-gradle-spring directories shows how this sits next to a Spring application.

Maven Central, a 4.x line, and a Spring integration

The package is published to Maven Central under the cz.habarta.typescript-generator group, with the core artifact at typescript-generator-core, and there is a Java CI workflow building the project on every change. The release history is worth reading closely because the version scheme changed. v4.1.1 was tagged on 2026-05-11 and v4.0.0 on 2026-04-06 with the release title To the Moon Again, but before that the project was on a v3.2.1263 scheme from 2023-03-20, so the jump from 3.2.1263 to 4.0.0 is a change of numbering convention as much as of version number. The README links a breaking changes wiki page and a release notes page, which are the two things to read before upgrading a project that pins a version. There is also a beta playground linked for trying the tool without setting anything up locally.

Editorial conclusion

typescript-generator fits a team with a Java REST service and a TypeScript client that has drifted apart, because generating the interface file from the same classes the server serialises removes the hand-maintained duplicate and its drift, and the plugin runs inside the normal build so the definitions cannot fall behind the code. It is a poor fit if your Java types are not the ones Jackson maps, since the tool works by reflection over compiled classes rather than over source. Verify first which input selection strategy fits your codebase, since the classes, classPatterns and JAX-RS application options behave differently for a hand-written resource class versus an auto-discovered one, and check the breaking changes wiki before moving to 4.x, where the version scheme changed sharply.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vojtechhabarta/typescript-generator on GitHub