▶ YouTube Summaries

• https://www.youtube.com/watch?v=nZ9PBEXyBYA
• Original title: My IntelliJ IDEA Setup for Java Development

Forrest Knight walks through the IntelliJ IDEA setup he has refined over roughly seven years of Java development, in a video sponsored by JetBrains and pegged to the 2026.2 release. He covers the settings he changes first (heap size, memory indicator), how he mixes AI agents in the terminal and in the IDE's built-in chat, the editor features he leans on (command completion, live templates, actions-on-save formatting), navigation and refactoring habits, his testing setup with Testcontainers and split run configs, lesser-known debugger tricks like mark object and drop frame, and a set of Spring-specific and general plugins. His framing throughout is that the IDE should get out of the way while still doing everything he needs.

# Performance and baseline settings

He uses his own unpublished theme called "Forest Night" and sticks with the default JetBrains Mono font. The single most important change he makes is raising IntelliJ's max heap size from 2 GB to 8 GB — this passes -Xmx for the IDE itself, separate from Gradle, the compiler, or the running application. Despite having 128 GB of RAM he stays at 8 GB, because that is the sweet spot: indexing and search get faster and GC stalls drop, but beyond 8 GB the GC pauses he does hit become noticeably longer. He enables the memory indicator to watch usage live, noting the displayed max grows dynamically (2200 M → 2400 M → 2600 M when syncing Gradle) because the JVM adjusts allocation on demand. He admits he should disable unused plugins to reclaim resources, but hasn't gotten around to it.

# AI in the workflow

For pure prompting he opens Claude Code in the integrated terminal, since the subscription plans are heavily subsidized compared to API pricing; he has configured the Claude command with --dangerously-skip-permissions so it launches with bypass permissions already on. He points out that the agent picks up the project's Java version rather than the system one, avoiding arguments about which JDK is correct. Because Codex allows using its plan inside other IDEs, he runs Codex through IntelliJ's built-in AI chat so he can watch changes land in the IDE in real time; Claude agent, GitHub Copilot, and others work there too via API. Agents launched from the IDE now get bundled skills exposing IntelliJ functionality over MCP, notably the IJ debugger skill for inspecting Java runtime state by just asking.

He still writes code by hand in the editor, but relies on AI inline code completion, which infers the rest of a block from the pattern above and is accepted with Tab, usually needing only small manual corrections afterwards.

# Command completion and live templates

Command completion is the feature he says he has adopted most recently, because it removes the need to memorize shortcuts. Typing .. at a position offers contextual actions: block or line comment, expand lambda body, ask AI, reformat, wrap in try/catch, extract a method, apply a fix, generate code, wire a Spring bean. A single dot mixes those with ordinary completion.

He argues live templates are underrated. Beyond the familiar sout, soutv prints a variable along with its value, and IOP produces an IO.println. New in this release, typing ..live lists the live templates available in the current context.

# Formatting

He keeps actions-on-save enabled with reformat code and optimize imports, with code style configured per language, so every save normalizes the file and the team's codebase stays consistent. He has since moved the responsibility into the build using Spotless, so formatting lives in the build rather than in each developer's IDE. He uses Palantir's Java formatter, both because he prefers its output to Google's Java formatter and because many teams use it. One caveat: with Palantir plus Spotless you must use IntelliJ's import ordering, since Palantir provides none and Spotless will otherwise fail on unordered imports.

# Navigation and refactoring

He does not use Vim motions. Double-Shift (Search Everywhere) is his main entry point for classes, files, symbols, actions, plugins, and slash commands. Command completion also works for navigation — .. next to a class name lets him jump into its members. To learn keybindings he installs Key Promoter X, which pops up the shortcut he should have used whenever he clicks a menu item (for example Alt+F12 for the terminal); the annoyance of the popup is what actually teaches the shortcut, and suppressing it is "cheating". Git Toolbox gives inline per-line Git blame showing author, time, and commit. For renaming he uses Shift+F6 (rename refactoring) rather than find-and-replace, because it is scope-aware — renaming a count field in User won't touch the identically named field in Order.

# Testing

He runs tests from the gutter, either the whole class or a single method, so after a fix he can rerun exactly what changed. He keeps two run configurations: fast unit tests he can run continuously while coding, and slower integration tests. Integration tests use Testcontainers — disposable lightweight Docker containers — spinning up a real PostgreSQL, running against it, then discarding it; in Spring 4 the wiring is a single @ServiceConnection annotation. His reason for using a real database instead of mocking the repository is that he has shipped data-layer bugs that got past mocks but would not have got past a real database. The Randomness plugin (Alt+R) inserts random data such as UUIDs directly into tests.

# Debugging

Beyond breakpoints and conditional breakpoints, he notes that middle-clicking a breakpoint disables rather than deletes it, preserving its condition — a trick he has found surprisingly many developers don't know. His favourite tool for chasing state bugs is mark object (F11): label a specific instance, then use that label as a breakpoint condition so the debugger only stops for that object. Drop frame rewinds the stack to before a method call when you have stepped one line too far, avoiding a full restart and bug reproduction — with the caveat that side effects such as database writes already happened and are not undone. The new IJ debugger skill in 2026.2 can perform much of this on request. He also highlights local history, IntelliJ's own per-file version history independent of Git, for reverting uncommitted changes.

# Spring-specific tooling

As a Spring developer he recommends the Spring debugger, which shows inlay hints for which beans were actually injected, lists beans in a panel, and allows navigating straight to a bean definition. The built-in HTTP client replaces Postman for him: clicking the globe icon next to a mapping annotation generates a request as a plain-text .http file that runs from the editor, can be committed to the repo, and can be switched between local and staging via environment files. JPA Buddy stays installed as a convenience — after years of writing JPA he doesn't need it, but generating an entity or DTO is still faster than typing one.

# Other plugins

SonarQube for IDE (formerly SonarLint) acts as an inline reviewer for bugs, code smells, and odd patterns. Maven Helper analyzes dependencies for version conflicts. String Manipulation converts case (for example to camel case) across many variables at once. The .ignore plugin generates and manages .gitignore files with syntax support. He closes by noting not everything shown is groundbreaking — some is obvious, some is idiosyncratic — but he wanted to cover the full mainstay workflow.