Add formatter step to shorten unnecessary fully qualified class names

[adwsingh]

Motivation

With LLM generated Java code becoming common, I am seeing one pattern a lot: generated code often uses fully qualified class names instead of normal imports.

The code compiles fine, but it becomes unnecessarily noisy.

For example:

package com.example.service;

public class UserService {
    private final java.util.Map<String, java.util.List<String>> cache = new java.util.HashMap<>();

    public java.util.List<String> getUsers(java.util.function.Predicate<String> filter) throws java.io.IOException {
        java.util.List<String> result = new java.util.ArrayList<>();
        return java.util.Collections.unmodifiableList(result);
    }
}

Running the formatter on this today leaves it unchanged.

Proposed behavior

Add a formatter step that shortens safe fully qualified names and adds the required imports:

package com.example.service;

import java.io.IOException;
import java.util.ArrayList;
import java.util.Collections;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.function.Predicate;

public class UserService {
    private final Map<String, List<String>> cache = new HashMap<>();

    public List<String> getUsers(Predicate<String> filter) throws IOException {
        List<String> result = new ArrayList<>();
        return Collections.unmodifiableList(result);
    }
}

This can run before RemoveUnusedImports and ImportOrderer, so the existing formatter steps can clean up and order imports after this step.

Why this belongs in the formatter

This is a mechanical cleanup and the formatter already handles import cleanup. This fills the other side of that flow: unnecessary fully qualified names can become normal imports.

This is showing up more often with AI generated code, and formatter runs in CI / pre-commit hooks where IDE cleanup actions are not always available.

I am ready to create a PR if the feature is acceptable.

[andrej-urvantsev]

Imho, this does not belong to the formatter. FQN sometimes must stay that way and it's not up to the formatter to decide this.

Please don't fix what's not broken. Fix it in neuro-slope layer instead.

[adwsingh]

FQN sometimes must stay that way and it's not up to the formatter to decide this.

I am curious to know in which cases. FWIW, I am proposing we only do remove FQNs when its unambiguous, like if there are multiple classes with different package names then using the FQN makes sense and we don't touch it in those cases.

[andrej-urvantsev]

Sometimes it's useful in object mappers for readability. In any way - it is not a part of the code formatter imho. You're trying to mitigate problem produced by neuro-slope at the expense of other tools.

Fix the cause instead.