Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider support for JSpecify nulllness (when the time is right) #390

Open
kevinb9n opened this issue Sep 13, 2022 · 1 comment
Open

Consider support for JSpecify nulllness (when the time is right) #390

kevinb9n opened this issue Sep 13, 2022 · 1 comment

Comments

@kevinb9n
Copy link

kevinb9n commented Sep 13, 2022

I wanted to preserve @stephan-herrmann's comment from the just-closed issue #379; if this wasn't the right thing to do please close with my apologies.


If you want to do something in NP area, consider add support to https://github.com/jspecify/jspecify in JDT, because that is supposed to be next "common" NP annotations standard.

So they are getting closer to a first release? That's probably a sound option moving forward (although I would add "quasi-" or similar in front of "standard", right? :) )

Note: I'm not sure if JDT implementation is compatible with jspecify, it just happened to me to know about that initiative.

Please let me know if you see some kind of test suite that we could use to test compatibility.

At a quick glance the annotations could be made to match with a little tweaking behind the scenes:

  • @NonNull & @Nullable can be mapped directly (good to see TYPE_USE of course)
  • @NullMarked is similar to our @NonNullByDefault, just ours can be fine-tuned, so one would need to figure which detail locations are covered by @NullMarked.
  • @NullUnmarked looks like our @NonNullByDefault({}) (i.e., apply the default at no locations.). We don't currently have a configuration option for that.

This should go a long way for a quick integration, but still there will be fine points in the semantics. That's why I asked for tests.


My (@kevinb9n) responses:

"Quasi-standard" is fair. :-)

We are pretty close to a "complete" design, i.e. that has an answer for every question (even if we're not sure it's the right one). We're still just calling that "0.3" and there will be a (lengthy) period for public feedback, during which all of these "answers" are still subject to change.

A good thing to read is the current javadoc.

We have some "samples" available, but also a proposal for turning them into proper tests which would (we hope) require you to write only some glue code; I can share that doc with interested individuals.

Please feel welcome to file issues at us or comment on them.

Lastly, we continue to welcome someone to represent Eclipse IDE and/or JDT in our group. The last we knew, there was no one with the right combination of interest, expertise, and time, but perhaps at least "interest" might trend positively as we start actually delivering anything. :-)

@stephan-herrmann
Copy link
Contributor

Thanks @kevinb9n

I still occasionally work on JDT's null analysis, so if anyone wants to work on this issue, I'll be available for questions, hints and reviews.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants