Hello! We were wondering if we could get rid of the intellij-inspections check from Apache Druid repo. Reasoning: 1. We have

maven-checkstyle-plugin

plugin integrated which uses checkstyle.xml. 2. We also have spotbugs integrated in our CI pipeline which does static analysis as well With the above, it seems a bit redundant to have a separate intellij-inspections check. It also adds unnecessary maintenance overhead. We are currently using https://github.com/ccaominh/intellij-inspect which is tied down to an openjdk8 image, and the project doesn't seem to be actively maintained. We would appreciate your thoughts and inputs on the above. If it sounds good, we will work on removing the check from the repo. Thanks!

I think we should remove it because: • I could not find other apache projects ever using it. • We also have other spotbugs checks which serve a similar purpose.

hmm, i seem to remember it having some checks that the other ones do not have

it definitely does sometimes catch things that the others dont. mostly i remember it being a flagger of "unnecessary throws"

Thanks for the inputs! I went through the latest 75 failures of IntelliJ check, summarizing it below in different categories. IntelliJ check errors out, but other static checks don't: 1.

The declared exception <code>IOException</code> is never thrown

(CI run) 2.

Class is not instantiated

/ `ulliMethod owner class is never instantiated OR/liliAn instantiation is not reachable from entry points./li/ul`(CI run) 3.

Method is never used.

(CI run) 4.

Field is assigned but never accessed.

(CI run) 5.

Cannot resolve symbol <code>prepareResource(GroupByQuery, BlockingPool, boolean, GroupByQueryConfig, GroupByStatsProvider)</code>

(CI run) 6.

Variable <code>row</code> initializer <code>null</code> is redundant

(CI run) IntelliJ check errors out, but is covered in other static checks: 1.

Missing '@Override' annotation on <code>getResultRowSignature()</code> #loc

(CI run) a. This is already covered in

(openjdk17) strict compilation

check IntelliJ check errors out, but unsure if it's covered in other static checks: 1.

Explicit type arguments can be inferred

and

Type parameter <code>T</code> hides type parameter 'T' #loc

(CI run) a.

(openjdk17) strict compilation

check errored out with something else before it got to these files, so not sure if it would have caught the above as well. 2.

Method is never used as a member of this interface, but only as a member of the implementation class(es). The project will stay compilable if the method is removed from the interface.

(CI run) a. Other static checks errored out earlier on packaging check with some other issues, so not sure if they would have thrown this error (especially the strict compilation check). Other than the above, we also have some (although rare) occurrences of the IntelliJ check failing in around 6 hours (CI run). I'm not able to download the log to see what happened there.

wow thanks for doing the analysis 👍

the image itself doesn’t seem all that complicated

IIUC we don't own the project, so is it allowed to fork and make changes and deploy on someone else's DockerHub? Although regardless of that, it seems like an extra piece to maintain in the long run, which seems unnecessary to me. Qodana seems interesting, thanks for sharing that!

yea, was teamcity https://github.com/apache/druid/pull/9179

Even I find Qodana stuff very interesting. So lets do this • Move out of intellij inspect • Remove java 8 support • Explore Qodana stuff in parallel since we would need some back nd forth with them to white list our project.

@Karan Kumar Sounds good to me, makes sense!

yea, 👍