Setting up an IDE for Java

You have compiled and run by hand, so you know what the IDE is going to do for you. Now set it up, and change the three settings that are worth changing before you start.

#Which one

IntelliJ IDEA Community Edition is the default for Java. Free, no account, and what most Java teams use. The paid Ultimate edition adds framework support (Spring, JPA tooling) that is genuinely useful later and unnecessary now.

VS Code with the Extension Pack for Java works well and is lighter, and is the obvious choice if you already live there for other languages.

Eclipse is free and capable and has fewer users each year.

Pick one. Learn it properly — its shortcuts, its debugger, its refactorings — rather than using three at ten per cent.

#Point it at the JDK you chose

This is the one setup step that actually matters, because the IDE has its own idea of which JDK to use and it is often not yours.

IntelliJ — File → Project Structure → Project SDK. Set it to the JDK you installed, and set the Language level to match. If the list is empty, add it by pointing at your JAVA_HOME directory.

VS Code — java.jdt.ls.java.home in settings, and java.configuration.runtimes if you keep several.

Then check it agrees with your terminal. Print the version from inside a program:

System.out.println(System.getProperty("java.version"));
System.out.println(System.getProperty("java.home"));

Run that in the IDE and compare it with java -version in your terminal. If they differ, you have two JDKs and two answers, and the day they disagree about something subtle you will remember this.

#Three settings worth changing on day one

1. Turn on automatic imports. IntelliJ: Editor → General → Auto Import → add unambiguous imports on the fly, and optimise imports on the fly. It removes a constant small friction.

The caveat is worth stating because it bites: when two classes share a name — and List, Date and Logger all have several — the IDE picks one. Glance at the import when you type a class name you have not used in this file before.

2. Make the formatter automatic. Format on save, or a keyboard shortcut you actually press. Consistent formatting is not about beauty; it is about diffs. A commit that changes one line should show one line, not forty because your editor re-indented.

Better still, if the project has a .editorconfig or a formatter configuration, the IDE should be reading it. Then everybody's output matches without anybody negotiating.

3. Learn four shortcuts before anything else. Not thirty. Four:

The first two are the ones you will use hundreds of times a day. Reaching for the mouse each time is a real tax on how far you can follow a thought.

#Turn on what will save you

Compiler warnings as something you read. The IDE flags unused variables, unreachable code, a null check that cannot fail, resources never closed. Most are worth acting on. The ones that are not can be suppressed deliberately, which is better than an editor full of yellow you have learned to ignore.

The debugger, and knowing where the button is. You will need it in your first week. The foundations course covers the method; find the breakpoint gutter and the step buttons now, while nothing is broken.

#What not to do yet

Do not install a pile of plugins. The defaults are good. Add one when you have felt the specific absence.

Do not adopt somebody's keymap. Learn the four above in your IDE's own bindings; remapping before you know what you are remapping makes every tutorial harder to follow.

Do not let the IDE be the only way you build. Run mvn test or ./gradlew build from the terminal at least once on any project you work on. That is what CI runs, and the first time the two disagree you want to already know how to ask the build directly.