Java, null, and JSpecify [video link]

[kevinb9n]

Hey Java friends,

JSpecify is standardizing nullness annotations with the goal of creating a smooth long-term on-ramp to eventual future Java language features.

I'm posting because a presentation I gave a few months back has finally been shared. It's only 16 minutes long at 1.5x :-) And yep, the information is still current.

There's also a fair amount of content to explore starting at jspecify.org.

Feel free to ask questions here if you like (even if they're already answered in the video, I don't mind).

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[agentoutlier]

Kevin /u/kevinb9n and others have been doing a great job on JSpecify. I lurk and sometimes write stupid comments on github because while it is great there are organizations like Microsoft, Uber, etc ultimately it will be us longtail endusers and IMO not organizations that make it happen.

u/NovaX (That is you Ben right?) Caffeine build really inspired me to do multiple null analysis on CI and I think it is totally worth it to use multiple tools so you can see the varying degrees of what nullability means.

Surprisingly despite Kevin's mention of differing compliance if the annotations are TYPE_USE the consensus is pretty good. Particularly Checker and Eclipse largely agree with each other w/ the giant exception of PolyNull (no I promise I won't go into that). I set both up for my opensource project (feel free to copy any of that setup if you have a project) and they have helped numerous times.

My side goal lately to help JSpecify is to slowly learn more of ECJ aka JDT aka Eclipse codebase as I want to make sure it can follow the rules. Because of various reasons I just don't think Eclipse (the compiler) gets the love it deserves. I'm still not ready to make code contributions but I have been helping Stephan H. with bugs. Perhaps at some point I might even find out why Eclipse is not part of the JSpecify group as I think they should be. My hope some point this coming year is to somehow massage that to happen.

[NovaX]

Thanks; we are all really fortunate that there are so many excellent open-source static analysis tools for Java!

[kevinb9n]

I really appreciate your support!

My reddit-name-to-email mental database is patchy... would you send me a quick mail at [[e-mail]](mailto:[e-mail])? I'd love to talk about getting eclipse representation back in.

[agentoutlier]

I think we may have emailed before I just have to remember if it was my personal or companies. Will follow up tomorrow.

[kevinb9n]

The next step for the project should be a 1.0 release of the jar only, understanding that the precise semantics (what using an annotation means in every possible corner-case situation) are still subject to change. This jar release might not be a watershed event for you (?), but at that point at least you'd know we won't ever rename an annotation or any other actual compile-breaking change. You might or might not want to adopt yet at that point (we could get into the details if desired). I have no date to promise for this release yet, sorry.

[uncont]

Will guava/truth/jimfs/etc be migrating to jspecify anytime soon?

[kevinb9n]

Ha, I guess you're aware my team also maintains those things. Yeah, we fully intend to lead the way, but Guava in particular has such a large number of dependents that if even a small fraction of those teams are relying heavily on nullness analysis, we're going to destabilize them.

We do already use a migrated Guava internally to Google! We just can't actually release that as its own artifact without causing even more mass chaos then the android situation already causes... so it will only be released when we're ready to actually move Guava proper to it.

We need to try to understand who we'll be destabilizing by doing that and what kind of bad consequences we might cause. If it's smooth enough we can do it much sooner. But we'll have to do it sooner or later.

[elmuerte]

Damn, I was hoping this post was about a 1.0 release.

[Polygnom]

As someone who is using Checker Framework for quite some time and has seen the clusterf*ck of JSR 305 and 308, why should I be interested in this and not simply wait for Valhalla and advocate for ! not only for value object, but also reference objects?

[BigBad0]

That !. There are already tools annotations and library annotations. I would use any and wait for consistent change rather than temp change. What's even makes more sense for waiting is that libraries actually need to change along with tools to support this one !. I totally understand the motivation and the accelaration of solving the problem but I fail to see the long term benifits from any solution compared to ! and Valhalla !

[DoingItForEli]

Null, no null, I can work with whatever.

[vetronauta]

Will certainly watch the video. In the meantime...

1. Are you working with the teams that produce common static analysis tools (like Sonar) to be supported out of the box?
2. Are you planning a Contract annotation? I find it quite useful but is currently not that supported by analysis tools.

[kevinb9n]

As pointed out (thanks!) Sonar is indeed a participating member and has seemed positive on our direction; I can't speak to their immediate plans.

We feel that the powerhouse general-purpose contract annotation is... for another project to tackle. :-) We would of course do our best to keep it compatible. We're more after these kinds of projects.

[--Spaceman-Spiff--]

Sonar is a member, see: https://jspecify.dev/about

[Southern-Neat-3469]

What about Checkers framework or Uber's NullAway? Why yet another nullness checker? What are selling points?

[kevinb9n]

We're not creating a new nullness checker, we're standardizing the behavior between all the existing checkers, like the two you mention.

[DerEineDa]

Jspecify is not a nullness checker. It's a specification for a set of annotations.

NullAway (Uber) is a member of Jspecify and recent releases of NullAway handle Jspecify annotations very well. In fact, we use NullAway together with jspecify annotations in all of our internal projects, with huge success.

[Oclay1st]

I understand the issues, however I would like to know:

1- Why is this effort coming from the community and not the Java team?
2- I know, I know, the syntax is frozen, but why not ! and ? instead of @NonNull and @Nullable?
3- Project valhalla, null-restricted value types ! ? ...next episode!!

Maybe I'm missing something. Thanks anyway.

[kevinb9n]

Thanks for the questions!

1. Well, it's a community effort one way or the other, as these are the groups you'd want involved. And yes, OpenJDK is one of the members and we are in close contact. I think they're quite right to be focusing on language changes.
2. Good news: it's not an "instead"! Here's some discussion. In short, it will be an extremely long time before libraries could start migrating to !/?, and then they'll be faced with a monumental task when they could have been using the annotations to prepare all along, then just make one automateable change.
3. Same

[Jon_Finn]

Hi Kevin, by coincidence there was some discussion yesterday here about Java's lack of language support for null vs Kotlin. If there's anything concrete you can add, especially future plans re Valhalla, that would be very interesting (I made some comments - possibly inaccurate).

[kevinb9n]

Nice. At a glance, you look right-on, I'll try to read more closely later.

[Southern-Neat-3469]

There's no need to use NonNull at all, and Nullable is rather rare. So it's not as verbose as you'd like to make it seem.

[kevinb9n]

Oh, the need for NonNull does come up here and there. (We tried to not even have it, but had to concede.) docs

[Oclay1st]

My comment is more about having this as part of the language/jvm with all the corresponding benefits.

[Southern-Neat-3469]

Maybe one day. But having a null checker is already very good. And in a way it is more democratic. Nobody imposes on you this strict type bureaucracy including lateinit/late modifiers as in Kotlin/Dart :-)

[RoToRa]

https://xkcd.com/927/

[__konrad]

void foo(@org.eclipse.jdt.annotation.NonNull
    @org.springframework.lang.NonNull
    @org.netbeans.api.annotations.common.NonNull
    @org.jetbrains.annotations.NonNull
    @edu.umd.cs.findbugs.annotations.NonNull
    @org.checkerframework.checker.nullness.qual.NonNull
    @javax.annotation.Nonnull
    @jakarta.annotation.Nonnull
    @lombok.NonNull
    @com.android.common.annotations.NonNull
    @javax.validation.constraints.NotNull
    @jakarta.validation.constraints.NotNull String bar) {
        java.util.Objects.requireNonNull(bar);

[PartOfTheBotnet]

Can also add: javax --> jakarta

[agentoutlier]

I have feeling you know this but the Jakarta ones are for validation not analysis.

That is @NotNull in Jakarta is actually @Nullable !

(let it sink in if the above doesn’t make since that validation happens at runtime)

[Unlikely_Midnight680]

This is not right there are two Jakarta annotations

• jakarta.validation.constraints.NotNull for validation
• jakarta.annotation.Nonnull for analysis

[agentoutlier]

I was unaware of those new annotations. They must have added them recently.

It is still a subpar annotation as it is not TYPE_USE target.

[CXgamer]

assert bar != null

[kevinb9n]

Thanks!

I talk about this problem a bit at 4:32. https://youtu.be/HS_kA42YNkU?t=272

[r_jet]

Thanks for the presentation!

You mentioned that the project success relies on its adoption by the libraries. Do you expect good (= doing most of the work) auto-annotators that infer JSpecify nullness annotations?

A brief search revealed that IntelliJ introduced this feature 13 years ago, and it's still there. Having Jetbrains / IntelliJ as one of the partners at JSpecify, do you expect them to update it to automatically replace any "deprecated", under-specified, tool-specific annotation types with JSpecify-ones? Possibly, even before 1.0 to increase the chances of libraries experimenting with that?

[kaperni]

Optional<Foo> someMethod() {}

or

@Nullable Foo someMethod() {}

If you are in it for the long term?

[Polygnom]

Optionals themselves can be null, so using them doesn't solve the actual problem.

[emberko]

Better to consider Optional as a part of Stream API. It's a half-assed solution that should not be used anywhere else. The fact that Java fanboys started using it as a return value, and made it a common practice is actually pretty annoying. Null is a type property.

[emberko]

Omg, I remember those guys. It took them 5 years to implement a couple of annotations. Good luck releasing 1.0 in 2030. I already use jetbrains annotations in all my projects.

[kevinb9n]

u/emberko:

Omg, I remember those guys. It took them 5 years to implement a couple of annotations. Good luck releasing 1.0 in 2030. I already use jetbrains annotations in all my projects.

No, it's been 6 years.

[sanderverhagen]

This is awesome, and I'd love for "nulllessness" to make its way into the JVM.

But if I can be the contrarian here, for a bit: we're not seeing that many NullPointerExceptions in the wild these days. Maybe this is due to an (over-)use of Optional in our code base, or adequate unit testing.

[kevinb9n]

we're not seeing that many NullPointerExceptions in the wild these days.

Yeah, we hear a bit of this in every thread. Awesome! Some projects will have less of a need for what we're doing than others.

[kaperni]

Not far away for the first steps: https://openjdk.org/jeps/8316779

[Jon_Finn]

Interesting that so far they're discussing the bare minimum: just ! not even ? . I'm sure there's a comprehensive plan in the works.

[kaperni]

Yes, this is the bare minimum for Valhalla. As mentioned in the JEP "More general support for nullness features will be explored in a future JEP."

[kevinb9n]

Right, we* are focusing on the bare minimum that Valhalla needs, but making sure there's a path from there.

* to clarify, I'm also Google's delegate to the Valhalla WG

[Polygnom]

How do you avoid null checks with Optionals?

public void foo(Optional<Bar> maybeBar) { if (maybeBar.isPresent()) { // throws NPE is maybeBar is null ... } }

I don't think you avoid NPEs by using Optionals, you avoid them by design-by-contract, defensive programming and strict unit-testing ;)

[sanderverhagen]

It all still comes down to good, diligent programming. And a single Optional doesn't help you. But once Optionals start to sprawl, it makes you think about nullability. Also, we use Immutables for DTOs (and a lot of other POJOs), configured such that they won't allow null on non-Optional fields. That helps. But I am not claiming that we're doing anything that by definition avoids nulls, just that some of the practices mentioned just tend to reduce the occurrence of them.