When I run the build with that wildcard import, it fails:

> Task :junit-jupiter-api:checkstyleMain
[ant:checkstyle] [ERROR] /Users/sbrannen/source/junit5/junit-jupiter-api/src/main/java/org/junit/jupiter/api/condition/AbstractJreCondition.java:17:26: Using the '.*' form of import should be avoided - java.util.function.*. [AvoidStarImport]

> Task :junit-jupiter-api:checkstyleMain FAILED

In other words, this is already covered by Checkstyle.

In light of that, I am closing this PR.

With regard to the aforementioned removeWildcardImports() feature in Spotless, that does not yet appear to have been released in the Gradle plugin.

In any case, removing wildcard imports without replacing them with actual valid imports does not seem very helpful in my opinion.

gradle build -x test did not fail for me.

while having the same feat. spotless goes beyond annoying but fixing the issue. Actually there is no need to have checkstyle anymore if spot is configured, its ready to take over.

gradle build -x test did not fail for me.

Before submitting a PR (or before the core team pushes anything to GitHub), a full build with checks and tests is required.

./gradlew check will fail, as will ./gradlew build.

As for whether -x test should omit the Checkstyle checks, I suppose that is debatable.

right, sorry for that.

should omit the Checkstyle checks

Yes in maven it would be a verify phase, gradle has something similar for sure.

while having the same feat. spotless goes beyond annoying but fixing the issue. Actually there is no need to have checkstyle anymore if spot is configured, its ready to take over.

From what I can tell, the new Spotless feature does not "fix" anything.

Rather, it simply removes all wildcard imports, which can result in the code no longer compiling.

Thus, rather than "fixing" the code, I'd say it actually "breaks" the code.

Yes in this case its actually true, wanted to mention this detail as well. But the this is the exception. Normally spot will replace with equivalent fix. We will work on the full replacement that IDEA offers.

If IDEA is correctly configured, avoiding wildcards, this could be leveraged for skilled IDE users, as the non-compiling file will be open in an ease, and then imports are added automatically sometimes.

Or just replace the diff in IDE and apply the wildcard replacement. Yes thats complicated as requires one extra step.

While check just breaks, assuming it offers no navigation.

"breaks" the code

"Breaks" the build, assuming and hoping that you cannot deliver non-compiling code.

So that's ment to be a feature, but it still imposes a small risk on a build, if its not checking for compiling. This will cause problems with this solution and should be reconsidered.

For real security and stability, we should just fail the build on the spot and not change it, in my opinion.

Just changing the goal from apply to check, as a failing build, with manual interaction required, is the desired outcome.

This is a very small risk, but a real one.
So the step should just fail the build during apply, as a real apply is not currently possible—assuming other steps deliver intentionally breaking code.

Whats you opinion ?
@iddeepak
@Goooler

For real security and stability, we should just fail the build on the spot and not change it, in my opinion.

That is the exact behavior we currently have with the Checkstyle check. See #4704 (comment).

If IDEA is correctly configured, avoiding wildcards,

The same is true for any IDE that one uses to work on JUnit code, and the core JUnit team developers rely on that, as I assume most developers do.