Java prompts for ChatGPT, Claude and Codex

The best Java prompts state your JDK version, paste the real code with the full stack trace or tool output, and ask for a checkable result such as a modernized class plus a list of anything that behaves differently. Below are 12 Java prompts for ChatGPT, Claude, Claude Code and Codex covering modern language features, JDK upgrades, concurrency, debugging production problems and tests.

For general jobs such as explaining code, writing a regex or a commit message, see the coding prompts. For large cleanups, the refactoring prompts go deeper. The prompts here are specific to Java.

How to use these prompts

Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{jdk:21}} means JDK 21 unless you change it.

Three habits make the answers better:

• State your JDK version. Language features land in specific releases. Records were finalized in JDK 16 by JEP 395, sealed classes in JDK 17, and pattern matching for switch and virtual threads in JDK 21. The OpenJDK JDK project page lists JDK 27 as generally available since 15 September 2026.
• Paste tool output. Stack traces with every "Caused by" section, thread dumps and heap histograms beat descriptions.
• Ask for behavior changes. Refactors to streams, records or Optional can change equality, ordering or null handling quietly.

In an agent, name the classes and let it run mvn test or gradle test itself.

How do you modernize Java code with AI?

1. Modernize a class to current Java

For code written in Java 8 style. JEP 395 describes records as "classes that act as transparent carriers for immutable data."

Modernize this Java code for JDK {{jdk:21}}. Where it fits:
- data-only classes to records
- instanceof checks followed by casts to pattern matching
- if/else chains on type or value to switch expressions
- verbose local types to var where the type stays obvious
- anonymous classes to lambdas

Do not change public APIs or behavior. After the code, list every change
that could behave differently, especially equals, hashCode, toString,
serialization and frameworks that need a no-argument constructor.

{{code}}

2. Model a closed hierarchy with sealed types

For a fixed set of variants handled with instanceof chains or a type field. JEP 409 says sealed classes and interfaces "restrict which other classes or interfaces may extend or implement them," and JEP 441 brings pattern matching to switch.

This code represents {{concept:payment methods}} with a type field and
instanceof checks:

{{code}}

Rewrite it as a sealed interface with record implementations, and replace
the type checks with a switch expression that uses pattern matching and
has no default branch, so adding a new variant causes a compile error. JDK
version: {{jdk:21}}. Show how calling code changes, and list anything that
relies on the old design, such as JSON mapping or JPA entities.

3. Rewrite loops with streams, carefully

For collection-processing loops. Streams can be clearer, or much harder to debug, so ask the model to keep loops where they win.

Rewrite these Java loops with the Stream API where it makes the code
clearer, for JDK {{jdk:21}}:

{{code}}

Keep loops where a stream would be harder to read or needs side effects.
For each rewrite, check: ordering, null elements, duplicate keys in
toMap, checked exceptions inside lambdas, and whether the result list
must be mutable. Point out any change in behavior.

How do you upgrade to a newer JDK?

4. Plan a JDK upgrade

For moving an application across several releases. Two JDK tools find the riskiest code: jdeps with --jdk-internals finds dependencies on internal JDK APIs, and jdeprscan scans class files "for uses of deprecated API elements."

I am upgrading a Java application from JDK {{from:11}} to JDK {{to:21}}.

Build tool and key dependencies:
{{build}}

Output of jdeps --jdk-internals:
{{jdeps_output}}

Output of jdeprscan:
{{jdeprscan_output}}

Give me an upgrade plan ordered by risk: what breaks, what to replace it
with, which dependencies need newer versions, and what to test. Mark any
claim about a specific JDK change that I should confirm in the release
notes, and don't guess version numbers.

5. Fix a build that broke after an upgrade

For compile errors, test failures or startup errors right after changing JDK or a framework version.

After upgrading {{what:from JDK 17 to JDK 21}}, the build fails.

Error output:
{{errors}}

Build file (pom.xml or build.gradle):
{{build_file}}

Group the errors by cause. For each group, explain what changed, show the
fix, and say whether it is in my code, a plugin version or a dependency.
Fix the cause, not the symptom: no suppressing warnings or adding
--add-opens unless you explain why it is the only option.

How do you write concurrent Java safely?

6. Move blocking work to virtual threads

For services that spend most of their time waiting on I/O. JEP 444 finalized virtual threads in JDK 21 and says "A new virtual thread should be created for every application task," using constructs such as semaphores to limit concurrency instead of pools. JEP 491 in JDK 24 set out to "Improve the scalability of Java code that uses synchronized methods and statements."

This Java service uses a fixed thread pool for blocking I/O work:

{{code}}

JDK version: {{jdk:21}}.

1. Show how to run each task on its own virtual thread.
2. Replace the pool size limit with a Semaphore where a limit is still
needed, for example for a database with {{connections:20}} connections.
3. Find synchronized blocks or ThreadLocal use that could be a problem on
my JDK version, and explain why.
4. Say what to measure before and after to prove it helped.

7. Diagnose a thread dump

For a service that hangs or slows to a crawl. jcmd <pid> Thread.print prints all threads with their stack traces, as the jcmd documentation shows.

My Java service {{symptom:stops responding under load}}. Here is a thread
dump taken while it happened:

{{thread_dump}}

Find: deadlocks, threads blocked on the same lock, pool threads all
waiting on one resource, and threads stuck in I/O without timeouts. For
each finding, name the threads and the code location, explain the cause,
and suggest a fix. Tell me what a second dump a few seconds later would
confirm.

8. Make a class thread-safe

For a class that started single-threaded and is now shared.

This Java class is now used by multiple threads:

{{code}}

List every field and say whether concurrent access is safe. Then make the
class thread-safe with the simplest approach that fits: immutability,
concurrent collections, atomics or locking. Explain the choice, check for
check-then-act races and compound operations, and keep the public API the
same.

How do you debug Java in production?

9. Explain a stack trace

For long traces with nested causes. The root cause is usually in the last "Caused by" section.

Here is a Java exception from {{env:production}}, with the full stack
trace including every Caused by section:

{{stack_trace}}

Code for the frames in my packages ({{package:com.example}}):
{{code}}

Identify the root cause, explain the chain of exceptions in plain
language, and give the three most likely reasons it happened, ranked. Show
the fix for the top one and what to log if it happens again.

10. Find a memory leak from a heap histogram

For heap usage that climbs until an OutOfMemoryError. The jcmd documentation describes GC.class_histogram as providing "statistics about the Java heap usage" and marks its impact as high, so run it with care on a busy server.

My Java service's heap grows until it throws OutOfMemoryError after about
{{time:two days}}.

Two class histograms (jcmd GC.class_histogram), taken {{gap:an hour}} apart:
{{histograms}}

Code for classes that grew the most:
{{code}}

Find what is growing and what likely holds the references: static
collections, caches without eviction, listeners never removed,
ThreadLocals in pooled threads. Suggest a fix for each suspect and what to
look for in a heap dump to confirm it.

How do you write Java tests with AI?

11. Write JUnit tests

For classes with little coverage. Paste one existing test so the new ones match your style.

Write tests for this Java class using {{framework:JUnit 5 and AssertJ}}.

{{code}}

Cover the normal case, boundaries, null and empty inputs, and every
exception path. One behavior per test, with a display name that says what
is checked. Use parameterized tests where cases differ only in input. Mock
only external dependencies, not the class under test. Match the style of
this existing test:

{{example_test}}

12. Clean up null handling

For code full of null checks, or code that throws NullPointerException in production. Optional is meant for return values, so ask the model to say where it doesn't fit.

Improve null handling in this Java code:

{{code}}

- Return Optional from methods where "no result" is a normal outcome.
- Do not use Optional for fields, parameters or collections; return empty
collections instead of null.
- Validate required arguments at public entry points with clear messages.
- Mark what can and cannot be null using {{annotations:no annotations}}.

List every place where behavior changes, such as a method that now throws
instead of returning null.

What should you check before you accept the answer?

AI-written Java tends to slip in the same few places, so check these every time:

• Version mismatch. Look for APIs or syntax newer than your JDK, or old ones like raw types and Date in new code.
• Equality changes. Converting a class to a record changes equals, hashCode and toString. Check code that puts these objects in sets or maps.
• Swallowed exceptions. Search for empty catch blocks and catches that log and continue when they should rethrow.
• Real build output. Run the build and tests yourself, or have an agent run them and paste the results.

Turn your favorite one into a skill

When one of these prompts becomes a daily habit, make it a skill so Claude Code or Codex uses it automatically. The stack trace and modernize prompts are good first candidates. Paste one into the free SKILL.md generator, which needs no sign-up, and it becomes a valid SKILL.md. For general debugging habits, see the debugging prompts, and for test coverage beyond Java, the unit test prompts.

To keep prompts like these close, save them in Kipt. Your library lives as Markdown in a private GitHub repo you own, each blank stays fillable when you copy, and Cmd+K finds any prompt by name or tag.