Move to jspecify?

[iloveeclipse]

See https://jspecify.dev/blog/release-1.0.0/

I personally always disliked the fact that we had 42 different NP annotation libraries in Java.
I wonder if 1) we can move to jspecify annotations and 2) also configure them to be default instead of jdt annotations in JDT UI.

@stephan-herrmann : you are the expert in this area, WDYT?

[stephan-herrmann]

I have waited many years for a standard to emerge, ten years only for TYPE_USE annotations getting attention by others.

I will certainly look at the new kid on the block, even though it is not a standard.

Whether or not it is feasible to switch to those annotations without breaking users of JDT needs to be determined. While I was still involved in that initiative it didn't look like compatibility with prior art was high on their agenda, but I believe this has changed to some degree in the time since.

Just to call out the reason for my reluctance: it is not just about the fully qualified name of annotations, it is also very much about semantics which likely differs in many details.

[stephan-herrmann]

on ...

See https://jspecify.dev/blog/release-1.0.0/

... I see:

"We're still working on updating the specification to reflect all of our design decisions (ETA: end of August), but that's more useful to nullness analyzer implementers."

We still have to wait for this.

[stephan-herrmann]

Unfortunately, jspecify doesn't help even for the long standing discussion on @LazyNonNull or whatever its name, see #2829

[laeubi]

I just recently stumbled over JEP draft: Null-Restricted Value Class Types (Preview)

I personally always disliked the fact that we had 42 different NP annotation libraries in Java.

The problems with "standards" is they tend to proliferate

https://xkcd.com/927

[stephan-herrmann]

See #390 and for a partial step #3434

[Wooza]

As an avid JDT user, I would love to see JSpecify support.

To address some of the earlier discussion points:

"We're still working on updating the specification to reflect all of our design decisions (ETA: end of August), but that's more useful to nullness analyzer implementers."

We still have to wait for this.

From my naive point of view, it looks like the spec has been completed.

The problems with "standards" is they tend to proliferate

There was a JSpecify talk at KotlinConf, addressing this concern (even referencing the same XKCD comic), see the Slide deck page 15ff.
The bottom line was, that none of the 42 existing annotations were really standardized.

From what I understand, the long-term goal for the JDK is to finally address null in the type system with Null-Restricted and Nullable Types. Furthermore, the semantics of JSpecify are closely aligned with what the JDK intends to adopt (cf this Reddit comment from one of the JSpecify Contributors). So once nullability has been addressed in the JDK, it should be possible to mechanically transform the JSpecify annotations, e.g., to go from @Nullable String s to String? s. While proper nullability support is probably still several JDK releases away, it should be noted that JSpecify can be used today to already get the benefits of null-analysis. The adoption of JSpecify in the Java ecosystem is already considerable, with Guava, Spring and JUnit being the most prominent projects that have adopted JSpecify.

[stephan-herrmann]

As an avid JDT user, I would love to see JSpecify support.

To address some of the earlier discussion points:

"We're still working on updating the specification to reflect all of our design decisions (ETA: end of August), but that's more useful to nullness analyzer implementers."

We still have to wait for this.

From my naive point of view, it looks like the spec has been completed.

Thanks for the hint. This looks like good news.

The problems with "standards" is they tend to proliferate

There was a JSpecify talk at KotlinConf, addressing this concern (even referencing the same XKCD comic), see the Slide deck page 15ff. The bottom line was, that none of the 42 existing annotations were really standardized.

I'm still reluctant to call jspecify a standard (and yes, I had tried to participate in that standardization, and failed).

From what I understand, the long-term goal for the JDK is to finally address null in the type system with Null-Restricted and Nullable Types. Furthermore, the semantics of JSpecify are closely aligned with what the JDK intends to adopt (cf this Reddit comment from one of the JSpecify Contributors).

It would be great to hear a similar assessment from Brian Goetz. Has he spoken yet on this topic, i.e., on such semantic compatibility?

So once nullability has been addressed in the JDK, it should be possible to mechanically transform the JSpecify annotations, e.g., to go from @Nullable String s to String? s. While proper nullability support is probably still several JDK releases away, it should be noted that JSpecify can be used today to already get the benefits of null-analysis.

ECJ supports this kind of null-analysis since 2014. To get a better picture of the situation, it would be great if someone precisely captures the semantic differences between jspecify and ECJ's null annotation checking.

• Could we just recommend to define jspecify annotations as aliases for JDT's annotations?
• Could a few simple switches in the code allow users to adjust ECJ's analysis to comply with jspecify?
• Or would supporting jspecify require to implement a second independent analysis?

For a description of ECJ's analysis you may use the following links or ask me if you have detailed questions :)

• https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_type_annotations.htm&cp%3D1_3_9_1
• https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.jdt.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fjdt%2Fannotation%2Fpackage-summary.html&cp%3D3_1_0_9

[stephan-herrmann]

Linking some related issues:

• Consider support for JSpecify nulllness (when the time is right) #390
• Cannot get JSpecify annotations to work like org.eclipse.jdt.annotation specifically with generics #3434
• Add support for JSpecify annotations #4644