AutoGineer
Generated banner for Kotlin Tooling Java To Kotlin
Generated logo for Kotlin Tooling Java To Kotlin

Kotlin Tooling Java To Kotlin

JetBrainsOfficialCreated by JetBrainsDistributed by JetBrains

  • Skill
  • Workflow
  • Software development
  • Apache-2.0
  • No issues found
Download ZIP

From the author

Use when converting Java source files to idiomatic Kotlin, when user mentions "java to kotlin", "j2k", "convert java", "migrate java to kotlin", or when working with .java files that need to become .kt files. Handles framework-aware conversion for Spring, Lombok, Hibernate, Jackson, Micronaut, Quarkus, Dagger/Hilt, RxJava, JUnit, Guice, Retrofit, and Mockito.
— the description by JetBrains

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a disciplined, four-step methodology for migrating Java code to Kotlin. It includes framework-aware guidance for common JVM libraries such as Spring, Hibernate, Lombok, and others. The process emphasizes maintaining behavioral parity through a chain-of-thought approach, checking five specific invariants at each stage to ensure the resulting Kotlin code is idiomatic, safe, and maintainable.

What it does

  • Scans Java files to detect and load relevant framework-specific conversion guides.
  • Executes a four-step conversion process: 1:1 translation, nullability audit, collection conversion, and idiomatic transformation.
  • Validates code against five core invariants at every step to prevent regressions.
  • Provides instructions for preserving Git history during file renaming.
  • Offers a checklist for verifying compilation and behavioral consistency.
  • Handles common pitfalls like keyword conflicts, SAM ambiguity, and platform types.

When to use it

  • When migrating existing Java projects or individual files to Kotlin.
  • When you need to ensure converted code follows idiomatic Kotlin patterns.
  • When working with Java codebases that utilize frameworks like Spring, Hibernate, or Dagger.
  • When you need to maintain Git blame history while refactoring Java to Kotlin.

Advantages

  • Reduces manual effort by providing a systematic, repeatable conversion workflow.
  • Ensures framework-specific idioms are applied correctly through targeted reference guides.
  • Maintains code integrity by enforcing strict invariants throughout the transformation.
  • Minimizes common interop issues by addressing platform types and JVM annotations.

Usage examples

“Convert this Java file to idiomatic Kotlin.”
The agent will scan the file for frameworks, perform the four-step conversion, and output the resulting .kt file.
“Migrate my Java project to Kotlin.”
The agent will list all .java files, sort them by dependency order, and perform a batch conversion following the defined workflow.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/jetbrains/kotlin-tooling-java-to-kotlin/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip kotlin-tooling-java-to-kotlin.zip -d .agents/skills

Documentation by JetBrains

Java to Kotlin Conversion

Convert Java source files to idiomatic Kotlin using a disciplined 4-step conversion methodology with 5 invariants checked at each step. Supports framework-aware conversion that handles annotation site targets, library idioms, and API preservation.

Workflow

digraph j2k_workflow {
  rankdir=TB;
  "User specifies files" -> "Step 0: Scan & Detect";
  "Step 0: Scan & Detect" -> "Load framework guides";
  "Load framework guides" -> "Step 1: Convert";
  "Step 1: Convert" -> "Step 2: Write .kt";
  "Step 2: Write .kt" -> "Step 3: Git rename";
  "Step 3: Git rename" -> "Step 4: Verify";
  "Step 4: Verify" -> "Next file?" [label="pass"];
  "Step 4: Verify" -> "Fix issues" [label="fail"];
  "Fix issues" -> "Step 1: Convert";
  "Next file?" -> "Step 0: Scan & Detect" [label="batch: yes"];
  "Next file?" -> "Done" [label="no more files"];
}

Step 0: Scan & Detect Frameworks

Before converting, scan the Java file's import statements to detect which frameworks are in use. Load ONLY the matching framework reference files to keep context focused.

Framework Detection Table
Import prefixFramework guide
org.springframework.*SPRING.md
lombok.*LOMBOK.md
javax.persistence.*, jakarta.persistence.*, org.hibernate.*HIBERNATE.md
com.fasterxml.jackson.*JACKSON.md
io.micronaut.*MICRONAUT.md
io.quarkus.*, javax.enterprise.*, jakarta.enterprise.*QUARKUS.md
dagger.*, dagger.hilt.*DAGGER-HILT.md
io.reactivex.*, rx.*RXJAVA.md
org.junit.*, org.testng.*JUNIT.md
com.google.inject.*GUICE.md
retrofit2.*, okhttp3.*RETROFIT.md
org.mockito.*MOCKITO.md

If javax.inject.* is detected, check for Dagger/Hilt vs Guice by looking for other imports from those frameworks. If ambiguous, load both guides.

Step 1: Convert

Apply the conversion methodology from CONVERSION-METHODOLOGY.md.

This is a 4-step chain-of-thought process:

  1. Faithful 1:1 translation — exact semantics preserved

  2. Nullability & mutability audit — val/var, nullable types

  3. Collection type conversion — Java mutable → Kotlin types

  4. Idiomatic transformations — properties, string templates, lambdas

Five invariants are checked after each step. If any invariant is violated, revert to the previous step and redo.

Apply any loaded framework-specific guidance during step 4 (idiomatic transformations).

Step 2: Write Output

Write the converted Kotlin code to a .kt file with the same name as the original Java file, in the same directory.

Step 3: Preserve Git History

To preserve git blame history, use a two-phase approach:

# Phase 1: Rename (creates rename tracking)
git mv src/main/java/com/example/Foo.java src/main/kotlin/com/example/Foo.kt
git commit -m "Rename Foo.java to Foo.kt"

# Phase 2: Replace content (tracked as modification, not new file)
# Write the converted Kotlin content to Foo.kt
git commit -m "Convert Foo from Java to Kotlin"

If the project keeps Java and Kotlin in the same source root (e.g., src/main/java/), rename in place:

git mv src/main/java/com/example/Foo.java src/main/java/com/example/Foo.kt

If the project does not use Git, simply write the .kt file and delete the .java file.

Step 4: Verify

After conversion, verify using checklist.md:

  • Attempt to compile the converted file

  • Run existing tests

  • Check annotation site targets

  • Confirm no behavioral changes

Batch Conversion

When converting multiple files (a directory or package):

  1. List all .java files in the target scope

  2. Sort by dependency order — convert leaf dependencies first (files that don't import other files in the conversion set), then work up to files that depend on them

  3. Convert one file at a time — apply the full workflow (steps 0-4) for each

  4. Track progress — report which files are done, which remain

  5. Handle cross-references — after converting a file, update imports in other Java files if needed (e.g., if a class moved packages)

For large batches, consider converting in packages (bottom-up from leaf packages).

Common Pitfalls

See KNOWN-ISSUES.md for:

  • Kotlin keyword conflicts (when, in, is, object)

  • SAM conversion ambiguity

  • Platform types from Java interop

  • @JvmStatic / @JvmField / @JvmOverloads usage

  • Checked exceptions and @Throws

  • Wildcard generics → Kotlin variance

Files

references/frameworks/SPRING.md

Spring Framework Conversion Guide

When This Applies

This guide applies when the Java source contains imports matching org.springframework.*. This covers Spring Boot, Spring MVC, Spring Data, and Spring Security.

Key Rules

1. SpringApplication.run — spread CLI args

In Kotlin, String[] varargs must be spread with the * operator.

  • Java: SpringApplication.run(App.class, args);

  • Kotlin: SpringApplication.run(App::class.java, *args)

2. Constructor injection over @Autowired

Kotlin's primary constructor makes constructor injection natural. When a class has a single constructor, Spring auto-discovers it — remove @Autowired.

3. Stereotype annotations

@Component, @Service, @RestController, and @Repository target the class. Preserve these annotations exactly. No annotation site target is needed.

4. @Value annotation

Use @Value on constructor parameters. Escape $ in SpEL expressions to prevent Kotlin string template interpretation:

@Value("\${app.name}") val appName: String
5. @ConfigurationProperties

Convert to a data class only if the properties are immutable. For mutable configuration, use a regular class with lateinit var.

6. Spring Data repositories

Interface declarations convert directly. Replace Optional<T> return types with nullable T? in Kotlin for idiomatic usage.

7. @RequestMapping / @GetMapping / @PostMapping etc.

Preserve exactly. Where Java uses array initializer syntax for annotation parameters, use arrayOf() in Kotlin.

8. @Transactional

Preserve exactly. The class must remain open because Spring creates proxies via subclassing. Do not make @Transactional classes final.

9. @Bean methods in @Configuration classes

@Bean methods must be open so that Spring can override them in CGLIB proxies. Alternatively, apply the allopen compiler plugin with a Spring preset, which makes annotated classes and their members open automatically.

Examples

Example 1: Spring Boot Application Main Class

Java:

package com.acme;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

Kotlin:

package com.acme

import org.springframework.boot.SpringApplication
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication

@SpringBootApplication
open class Application

fun main(args: Array<String>) {
    runApplication<Application>(*args)
}

Key changes:

  • main becomes a top-level function (no companion object needed).

  • runApplication<T> is a Spring Boot Kotlin extension that replaces SpringApplication.run(T::class.java, *args).

  • The *args spread operator is required for the varargs parameter.

Example 2: REST Controller with Constructor Injection

Java:

package com.acme.web;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/api/users")
public class UserController {

    private final UserService userService;

    @Autowired
    public UserController(UserService userService) {
        this.userService = userService;
    }

    @GetMapping("/{id}")
    public UserDto getUser(@PathVariable Long id) {
        return userService.findById(id);
    }

    @GetMapping
    public List<UserDto> getAllUsers() {
        return userService.findAll();
    }
}

Kotlin:

package com.acme.web

import org.springframework.web.bind.annotation.GetMapping
import org.springframework.web.bind.annotation.PathVariable
import org.springframework.web.bind.annotation.RequestMapping
import org.springframework.web.bind.annotation.RestController

@RestController
@RequestMapping("/api/users")
class UserController(
    private val userService: UserService
) {

    @GetMapping("/{id}")
    fun getUser(@PathVariable id: Long): UserDto? {
        return userService.findById(id)
    }

    @GetMapping
    fun getAllUsers(): List<UserDto> {
        return userService.findAll()
    }
}

Key changes:

  • @Autowired is removed — Spring auto-discovers the single constructor.

  • The Autowired import is removed because it is no longer referenced.

  • Constructor parameter becomes a private val in the primary constructor.

  • Return type UserDto becomes UserDto? where the service may return null.

Example 3: @ConfigurationProperties Class

Java:

package com.acme.config;

import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

@Component
@ConfigurationProperties(prefix = "app.mail")
public class MailProperties {

    private String host;
    private int port = 587;
    private String username;
    private String password;

    public String getHost() { return host; }
    public void setHost(String host) { this.host = host; }

    public int getPort() { return port; }
    public void setPort(int port) { this.port = port; }

    public String getUsername() { return username; }
    public void setUsername(String username) { this.username = username; }

    public String getPassword() { return password; }
    public void setPassword(String password) { this.password = password; }
}

Kotlin (mutable config with lateinit var):

package com.acme.config

import org.springframework.boot.context.properties.ConfigurationProperties
import org.springframework.stereotype.Component

@Component
@ConfigurationProperties(prefix = "app.mail")
open class MailProperties {
    lateinit var host: String
    var port: Int = 587
    lateinit var username: String
    lateinit var password: String
}

Key changes:

  • Getters and setters are replaced by Kotlin properties.

  • lateinit var is used for required String properties that Spring populates after construction.

  • port keeps its default value and uses a regular var (lateinit does not support primitive types).

  • The class is open so that Spring can create a CGLIB proxy for it.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs a command-line tool

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
JetBrains
Publisher
JetBrains (Official)
Distributed by
JetBrains
Source
JetBrains/skills · kotlin-tooling-java-to-kotlin · commit 3f53782
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (written by AutoGineer)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by JetBrains or JetBrains.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download kotlin-tooling-java-to-kotlin.zip