Provide a "reasonable" way for early adopters to integrate into a Bazel build

[cpovirk]

Similar to #22 in the sense that we've done nothing for Bazel yet.

Internally, we use java_package_configuration. But there's a bit more to it than that, so we might just want to have people set exported_plugins on a common dep or something??

Anyway, we're tentatively leaving Bazel integration off the current milestone because Bazel is less common than Maven and Gradle. But if we hear of an interested party who uses Bazel, we can probably whip something up without too much trouble.

[vorburger]

But if we hear of an interested party who uses Bazel

An interested party is hereby raising interest for this interesting idea! 😄

IFF adopting this (jspecify-reference-checker) is recommended in enola-dev/enola#845?

[vorburger]

I guess the ("reasonable" ?) endgame here would be to have a jspecify-reference-checker up over on https://registry.bazel.build, which would let one easily switch their java_library over to (something like) a java_library_with_nullness_check sort of Bazel rule?

[cpovirk]

Thanks. I left a response over there. To elaborate a little here:

The primary value that the reference checker provides over EISOP is that the reference checker is more lenient when dealing with unannotated code.

The primary value that the reference checker provides over NullAway is that the reference checker has significant support for generics.

Given that, it's probably not the best choice for your particular project. If we had it ready to integrate easily, I'd for sure tell you to try just so that we get some more hands-on usage :) But now, it's strictly harder to integrate than EISOP, which I suspect is strictly harder than NullAway. We'll get there eventually, and I appreciate knowing of the interest. Still, I'd suggest not right now.