Kotlin Tooling Java To Kotlin
JetBrainsOfficialCreated by JetBrainsDistributed by JetBrains
- Skill
- Workflow
- Software development
- Apache-2.0
- No issues found
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
Download the skill as a ZIP:
https://autogineer.com/agent-skills/jetbrains/kotlin-tooling-java-to-kotlin/downloadUnzip 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 prefix | Framework 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:
Faithful 1:1 translation — exact semantics preserved
Nullability & mutability audit — val/var, nullable types
Collection type conversion — Java mutable → Kotlin types
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.ktIf 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):
List all
.javafiles in the target scopeSort 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
Convert one file at a time — apply the full workflow (steps 0-4) for each
Track progress — report which files are done, which remain
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/@JvmOverloadsusageChecked exceptions and
@ThrowsWildcard generics → Kotlin variance
Files
- ATTRIBUTION.mdAdded by AutoGineer1023 B
- LICENSEAdded by AutoGineer10.0 KiB
- SKILL.md5.6 KiB
- assets/checklist.md2.5 KiB
- references/CONVERSION-METHODOLOGY.md9.8 KiB
- references/KNOWN-ISSUES.md9.5 KiB
- references/frameworks/DAGGER-HILT.md4.3 KiB
- references/frameworks/GUICE.md4.5 KiB
- references/frameworks/HIBERNATE.md5.9 KiB
- references/frameworks/JACKSON.md7.1 KiB
- references/frameworks/JUNIT.md5.3 KiB
- references/frameworks/LOMBOK.md6.3 KiB
- references/frameworks/MICRONAUT.md3.3 KiB
- references/frameworks/MOCKITO.md7.7 KiB
- references/frameworks/QUARKUS.md3.8 KiB
- references/frameworks/RETROFIT.md4.4 KiB
- references/frameworks/RXJAVA.md5.6 KiB
- references/frameworks/SPRING.md6.3 KiB
references/CONVERSION-METHODOLOGY.md
Conversion Methodology
You are a senior Kotlin engineer and Java-Kotlin JVM interop specialist. Your task is to convert provided Java code into idiomatic Kotlin, preserving behaviour while improving readability, safety and maintainability.
The 4-Step Precognition Process
Before emitting any code, run through the provided Java input and perform these 4 steps of thinking. After each step, output the code as you have it after that step's transformation has been applied.
Step 1: Faithful 1:1 Translation
Convert the Java code 1 to 1 into Kotlin, prioritising faithfulness to the original Java semantics, to replicate the Java code's functionality and logic exactly.
Rules:
Java classes that are implicitly open MUST be converted as Kotlin classes that are explicitly
open, using theopenkeyword.To convert Java constructors that inject into fields, use the Kotlin primary constructor. Any further logic within the Java constructor can be replicated with the Kotlin secondary constructor.
Step 2: Nullability & Mutability
Check that mutability and nullability are correctly expressed in your Kotlin conversion.
Only express types as non-null where you are sure that it can never be null, inferred
from the original Java. Use val instead of var where you see variables that are
never modified.
Rules:
If you see a logical assertion that a value is not null (e.g.,
Objects.requireNonNull), this shows that the author has considered that the value can never be null. Use a non-null type in this case, and remove the logical assertion.In all other cases, preserve the fact that types can be null in Java by using the Kotlin nullable version of that type.
Step 3: Collection Type Conversion
Convert datatypes like collections from their Java variants to the Kotlin variants.
Rules:
For Java collections like
Listthat are mutable by default, always use the KotlinMutableList, unless you see explicitly that the Java code uses an immutable wrapper (e.g.,Collections.unmodifiableList()) — in this case, use the KotlinList(and so on for other collections likeSet,Mapetc.)
Step 4: Idiomatic Transformations
Introduce syntactic transformations to make the output truly idiomatic.
Rules:
Where getters and setters are defined as methods in Java, use the Kotlin syntax to replace these methods with a more idiomatic version.
Lambdas should be used where they can simplify code complexity while replicating the exact behaviour of the previous code.
The 5 Invariants
In each stage of your chain of thought, the following invariants must hold.
Invariant 1: No new side-effects or behaviour.
Invariant 2: Preserve all annotations and targets exactly.
Annotations must target the backing field in Kotlin where they targeted the field in Java. Use annotation site targets:
@field:,@get:,@set:,@param:.
Invariant 3: Preserve the package declaration and all imports.
Carry forwards every single import, adding no new imports. Only remove imports where they would shadow Kotlin names (e.g.,
java.util.Listshadows Kotlin'sList).
Invariant 4: Preserve all Javadoc comments.
In step 1, convert any Javadoc comments to KDoc comments.
In all other steps, carry forwards the KDoc comments, preserving information where structure changes.
Invariant 5: Ensure the output result is in Kotlin.
The emitted code must be syntactically valid Kotlin.
After each step, go through each of these invariants, listing the ones that no longer hold. If any exist, revert to the previous step and recalculate from there.
Example 1: Utility Class with Nullability
Java Input
package com.acme.util;
import java.time.LocalDate;
import java.util.Objects;
/**
* Utility for printing a greeting that includes the current date.
*/
public class DateGreeter {
/**
* Prints a greeting for the given name and the current date.
*
* @param name an optional name; if {@code null}, the greeting uses {@code "Guest"}
*/
public static void greet(String name) {
String who = (name != null) ? name : "Guest";
System.out.println("Hello, " + who + " - today is " + LocalDate.now());
}
}Conversion Walkthrough
Step 1 — Faithful translation. The DateGreeter class is implicitly open, the
greet method is static → companion object. Javadoc converted to KDoc.
package com.acme.util
import java.time.LocalDate
import java.util.Objects
/**
* Utility for printing a greeting that includes the current date.
*/
open class DateGreeter {
companion object {
/**
* Prints a greeting for the given [name] and the current date.
*
* @param name an optional name; if `null`, the greeting uses `"Guest"`
*/
fun greet(name: String?) {
var who = if (name != null) name else "Guest"
println("Hello, " + who + " - today is " + LocalDate.now())
}
}
}Invariants check: All OK.
Step 2 — The String? is correct since the author checks for null. The who
variable is only read, so change var → val.
// Same as above but with:
val who = if (name != null) name else "Guest"Invariants check: All OK.
Step 3 — No collections in this code. No changes.
Invariants check: All OK.
Step 4 — The greet function is not tied to any state of DateGreeter, so move it
to a top-level function. Use string templates and Elvis operator.
package com.acme.util
import java.time.LocalDate
import java.util.Objects
/**
* Prints a greeting for the given [name] and the current date.
*
* @param name an optional name; if `null`, the greeting uses `"Guest"`
*/
fun greet(name: String?) {
println("Hello, ${name ?: "Guest"} - today is ${LocalDate.now()}")
}Invariants check: All OK.
Example 2: Domain Model with Annotations
Java Input
package com.acme.model;
import com.fasterxml.jackson.annotation.JsonProperty;
import javax.annotation.Nullable;
import java.util.Objects;
/**
* Domain model for a user with a required identifier and an optional nickname.
* <p>
* The {@code id} is serialized as {@code "id"} and is required.
* The {@code nickname} may be absent.
*/
public class User {
/**
* Stable, non-null identifier serialized as {@code "id"}.
*/
@JsonProperty("id")
private final String id;
/**
* Optional nickname for display purposes.
*/
@Nullable
private String nickname;
/**
* Creates a user with the given non-null identifier.
*
* @param id required identifier for the user
* @throws NullPointerException if {@code id} is null
*/
public User(String id) {
this.id = Objects.requireNonNull(id, "id");
}
/**
* Returns the identifier serialized as {@code "id"}.
*
* @return the user id
*/
@JsonProperty("id")
public String getId() {
return id;
}
/**
* Returns the optional nickname.
*
* @return the nickname or {@code null} if absent
*/
@Nullable
public String getNickname() {
return nickname;
}
/**
* Sets the optional nickname.
*
* @param nickname the nickname or {@code null} to clear it
*/
public void setNickname(@Nullable String nickname) {
this.nickname = nickname;
}
}Conversion Walkthrough
Step 1 — Faithful translation. Class is implicitly open → open class.
@JsonProperty("id") on the field → @field:JsonProperty("id").
@JsonProperty("id") on the getter → @get:JsonProperty("id") when converted to
property later. Keep explicit getters/setters at this step for faithfulness.
package com.acme.model
import com.fasterxml.jackson.annotation.JsonProperty
import javax.annotation.Nullable
import java.util.Objects
/**
* Domain model for a user with a required identifier and an optional nickname.
*
* The `id` is serialized as `"id"` and is required.
* The `nickname` may be absent.
*/
open class User {
/**
* Stable, non-null identifier serialized as `"id"`.
*/
@field:JsonProperty("id")
private val id: String
/**
* Optional nickname for display purposes.
*/
@field:Nullable
private var nickname: String? = null
/**
* Creates a user with the given non-null identifier.
*
* @param id required identifier
* @throws NullPointerException if `id` is `null`
*/
constructor(id: String) {
this.id = Objects.requireNonNull(id, "id")
}
@get:JsonProperty("id")
fun getId(): String { return id }
@Nullable
fun getNickname(): String? { return nickname }
fun setNickname(@Nullable nickname: String?) { this.nickname = nickname }
}Invariants check: All OK.
Step 2 — id is non-null by design (Objects.requireNonNull enforces it).
nickname is nullable (@Nullable). No val/var changes needed beyond what's already
done. Code unchanged.
Invariants check: All OK.
Step 3 — No collections. No changes.
Invariants check: All OK.
Step 4 — Idiomatic Kotlin:
Primary constructor with
idas avalproperty. Apply both@field:JsonPropertyand@get:JsonPropertyto match both Java annotation targets.Convert
nicknamegetter/setter → Kotlin property with@field:Nullableand@get:Nullable.Drop
Objects.requireNonNull— Kotlin's type system enforces non-null.Preserve all imports even if now unused (invariant 3).
package com.acme.model
import com.fasterxml.jackson.annotation.JsonProperty
import javax.annotation.Nullable
import java.util.Objects
/**
* Domain model for a user with a required identifier and an optional nickname.
*
* The `id` is serialized as `"id"` and is required.
* The `nickname` may be absent.
*
* @property id stable, non-null identifier serialized as `"id"`
* @property nickname optional nickname for display purposes; may be `null` if not set
*/
open class User(
@field:JsonProperty("id")
@get:JsonProperty("id")
val id: String
) {
@field:Nullable
@get:Nullable
var nickname: String? = null
}Invariants check: All OK.
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