dependency on outdated `findbugs`
see here: https://github.com/opensearch-project/opensearch-java/blob/1a142711d6e4cf626d0c6f455445867633893544/java-client/build.gradle.kts#L202
there's a dependency on findbugs. i see two problems with this:
-
findbugsis dead since a decade, its successor isspotbugs -
findbugs/spotbugsis a tool usually used at build-time, not at runtime. however, this is anapi(and thus runtime) dependency ofopensearch-javaand thus being pulled in by all consumers
in the best case this gets removed, otherwise it should at least be replaced by spotbugs which is still maintained.
@rursprung I would distinguish that this is purely the JSR305 annotations (ie. javax.annotation.Nullable & co) not the findbugs analysis tool. As it's only annotation interfaces and contains no logic, I personally don't believe it's particularly high risk. This is also why it's an api dependency as public facing members are generally annotated with their (non-)nullability. As it's used in a publicly facing manner, removing or replacing it would almost certainly technically be a breaking change.
There are many possible replacement libraries, all of which have differing class/package paths due JSR305 never being adopted and so findbugs should never have used the javax.annotation package in the first case. We'd therefore have to settle on what the correct replacement should actually be (e.g. spotbugs or jakarta to name just a couple).
cc. @reta
@rursprung I would distinguish that this is purely the JSR305 annotations (ie. javax.annotation.Nullable & co) not the findbugs analysis tool. As it's only annotation interfaces and contains no logic, I personally don't believe it's particularly high risk. This is also why it's an api dependency as public facing members are generally annotated with their (non-)nullability. As it's used in a publicly facing manner, removing or replacing it would almost certainly technically be a breaking change.
I agree, thank you @Xtansia , the jsr305 is pretty much independent from findbugs (the tool)