Unfortunately, the editorconfig-maven-plugin doesn't support Java at the moment: for now the plugin has support to enforce coding style rules for other languages such as XML and YAML.

There are different Maven plugins that support Java linting, like the maven-checkstyle-plugin or the PMD plugin.

If you're looking for a tool to handle Java formatting based on .editorConfig, there are several options:

1. Eclipse IDE along with the Eclipse Code Formatter plugin.

2. IntelliJ IDEA IDE with the EditorConfig plugin

3. separate command-line tools such as the JHipster code generator or the Jalopy code formatter. These tools can be easily integrated into Maven build process to automatically format Java code based on the .editorConfig rules.

OP did not describe the proposed changes to default format (TAB == three SPACE, maybe?). More importantly, it did not describe the positive benefit which would outweigh the various frictional negatives detailed.

is it misguided to have this goal?

Yes.

Most editors can handle coding rules like "no TABs!" and "no trailing SPACE!" But to encode more subtle details like where the { } curly braces go, you kind of need to put the definitive instructions in one place, either a linter or preferably as pretty-printer styling which a readonly linter can verify. And they must be committed as part of the build process, perhaps run by mvn.

@Laiv's pre-commit suggestion is a good one. All my repos have a .git/hooks/pre-commit script; it's not burdensome. Among other things the scripts check for TABs and trailing SPACE.

Given such a standard belt, developers will seek suspenders that fit their IDE's workflow. A ReadMe can offer helpful advice for popular IDEs, advice that worked at some snapshot in time before the IDE changed. Ultimately each developer will have to explore what works for them at the present time in their IDE on their laptop.

A CI/CD linter should definitely fail the build in the (unlikely?) event that the desired linting gate didn't run properly on a committer's laptop.