Adam Gent

@sdeleuze prior to JSpecify which tools are/were using to validate the original [`@Contract`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/lang/Contract.html)? Is it IntelliJ headless? I confess while I have seen the annotations I have not used the...

> NullAway for example. But it is not NullAway. Its NullAway does not agree with IntelliJ correct? This is my whole thing with adding annotations in that it is not...

EDIT I'm realizing now that I misremembered / misread and thought you meant 97.7% time NullAway worked fine but needed Contracts for 100%. What you said is 97.7% code works...

Honestly @sdeleuze it pains me to be the bad guy. The guy who has to question features especially features that you have proven useful for Spring's codebase and apparently has...

Checkers `@EnsuresNonNull` and friends are actually more complicated than NullAway's version of `@Contract` and this proposal. Like the expression language it has allows you to do `@EnsureNonNull("this.x")` and not just...

> But... most developers don't want to do that, simply because it contradicts the DSL-style of assertions that developers have come to know and love. And I get that but...

@cpovirk Your comments remind me of another issue and kind of my slight impetus to not wanting new contract annotations is the potential to hurt backward compatibility. Assume we had...

> Am I overlooking other ways in which contracts could introduce errors in code that didn't previously have them? I kind of mention earlier that my overall problem with the...

FWIW Eclipse and thus in theory VSCode with the RedHat extension has an option to warn if null annotations are missing on a package. EDIT it also has an option...

@xtaixe I feel your pain but its one of those things that is minor pain compared to converting an existing codebase to JSpecify and dealing with the variability of tooling...