This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR.

Can we consider ast-grep for this? it is really fast and doesn't require regular expressions, has plugins for editors. I wrote a rule for this in less than a minute:

id: wildcard-import-not-allowed
language: java
rule:
  kind: asterisk
  inside:
    kind: import_declaration
severity: error
message: don't use wildcard imports
note: please use full import instead
url: https://whatever/explanation

I'll take a look, sure. I'll also try to figure out why the heck spotless isn't behaving the way it should.

Thanks for playing with it. I would be happy to try to write ast-grep rules to try to replace some of the slower error-prone checks, or whatever else (nocommit checks etc).

We could install the package via pip or npm in the GH actions to support the checker. At just a glance, many of the rules are basically trivial e.g. https://errorprone.info/bugpattern/EqualsNull.

From what I remember, each check has a high overhead for errorprone which I don't believe is the case for ast-grep. I know I'm oversimplifying it, but I assume each file is parsed only once and then all rules run similar to https://tree-sitter.github.io/tree-sitter/using-parsers/queries/1-syntax.html, but without the s-expressions :)

Well, if this patch goes in, all it takes to add a rule is to create a new file in gradle/validation/ast-grep - it should be picked up automatically. We can also make ast-grep a requirement (much like python, perl and git) in the long term if it proves to be beneficial.

I've taken a look at the tree sitter too, very interesting stuff. Gotta love how with all the cool languages out there, it's still C that prevails. :)

Another related idea here is to prevent any IDE from automatically adding the *'s we don't want.

Eclipse's default limit is 99 imports before it starts doing this... of course user can change, and some rare files might exceed this. there's a way to bump it to huge value (e.g. Integer.MAX_VALUE) in our eclipse settings, i think, but i don't have a concrete solution: https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/0b3651f030e2e68e43019268f35880a07aa7a8c5/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/preferences/Preferences.java#L345-L367

I don't know how intellij behaves here or if we can prevent similar behavior. All this stuff can be followups, really, I'm just brainstorming.

Thanks for the ast-grep though!!! Gives me a way to help speed up the checks :) I will leave a few comments, not review ones intended to block the change. I can help out with followup PRs.

I've forked the ast-grep thing into a separate PR - #14808. I think we can merge that one in, then I can apply a smaller patch for wildcards, using your rule.

I don't know how intellij behaves here or if we can prevent similar behavior. All this stuff can be followups, really, I'm just brainstorming.

We should be able to make it easier for IntelliJ to do the right thing without too much trouble. One option is to use gradle-idea-ext, which is what we do on OpenSearch (ref). Another option is to use a .editorconfig file, where there are some IntelliJ-specific extensions (like ij_java_names_count_to_use_import_on_demand) that can crank up the threshold for wildcard imports.

I can take a shot at a separate PR to help out there.

We should be able to make it easier for IntelliJ to do the right thing without too much trouble. One option is to use gradle-idea-ext,

I've never used this plugin - have it on my "to-check" list (!). It would be awesome to provide more reasonable IntelliJ defaults. My experience with using google-java-format plugin is that once you enable it, the import section formatting settings are completely ignored...

Ok. I think this one is ready.

FYI - spotless runs google java format in a single-thread, that's part of the reason it's sluggish. But it's still an order of magnitude slower than the c parser. I ran this, for the fun of it (this uses multiple threads for parsing):

> find . -name "*.java" > files.in
> wc -l files.in
5973 files.in
> time java -jar ~/tmp/google-java-format-1.27.0-all-deps.jar  -n --skip-reflowing-long-strings --skip-javadoc-formatting --skip-removing-unused-imports @files.in
real	0m5.338s
user	2m7.927s
sys	0m6.549s

The user time - compared to tree-sitter's 7 seconds - is rather pale.

@dweiss yeah, the parsers are generally fast. and the java one in particular is very nice. Of course they are doing a lot less, too.

parser test framework tracks the performance in terms of MB/s and warns if the speed gets too low:

  custom_tag:
      5. ✓ custom tag
      6. ✓ custom tag: inline
      7. ✓ custom tag: missing description
      8. ✓ custom tag: inline, missing description -- Warning: Slow parse rate (1671.346 bytes/ms)

Spotless now supports removing wildcard diffplug/spotless#2517 from 7.1.0. We can use the same

@owaiskazi19 thank you for the heads up. I opened #14960 for this.

I saw the spotless 7.1 PR go through but unfortunately nothing in the release notes in the dependabot PR about a new wildcard-remover feature: #14956

Except we're now using custom code to call into google java format... Eh.

Hmm... looking at the diff, the added step just removes wildcard imports - it doesn't resolve them (like intellij or eclipse would)? I don't know if this is that helpful.

Yeah, just removing them isn't "fixing" :)