FTR:

- JSR305
  https://jcp.org/en/jsr/detail?id=305
  Status: Dormant

- JSR308
  https://jcp.org/en/jsr/detail?id=308
  Status: Final

- https://dzone.com/articles/when-to-use-jsr-305-for-nullability-in-java

- The endless reddit references

With more links on the above pages.

Gary

On 2024/02/15 18:24:10 Benjamin Marwell wrote:
> OK, let's wait for the JEP to arrive then.
> 
> > Such a dependency would only be useful if compilers.
> > IDEs, and incremental compilers within IDEs (like in Eclipse) would
> > know about them to report warnings.
> 
> Luckily, at least the IDEs do. For maven builds, you'd need sth like
> the checker framework
> or Google ErrorProne. But not worth it for existing projects.
> 
> > I'm sure they'd want to do so through a JEP API
> 
> Yes, JSpecify tries to be what Joda was for java.time.
> At the moment, IntelliJ will just use any @Nullable annotation,
> and Eclipse can be configured (just add any fqcn).
> 
> I hope we get a little bit better parameter documentation, though.
> 
> Am Di., 13. Feb. 2024 um 04:11 Uhr schrieb Gary Gregory
> <[email protected]>:
> >
> > On Mon, Feb 12, 2024 at 6:33 AM Matthias Bünger
> > <[email protected]> wrote:
> > >
> > > (I'm neither a Maven core or plugin maintainer)
> > >
> > > I don't like such annotations as in my opinion, they save you nothing,
> > > but bring an addional dependency and problems with the tools that
> > > (don't) support (only a specific version of) them.
> >
> > I agree 100%. Such a dependency would only be useful if compilers.
> > IDEs, and incremental compilers within IDEs (like in Eclipse) would
> > know about them to report warnings. If they wanted to do that, then
> > I'm sure they'd want to do so through a JEP API, not
> > yet-another-attempt-at-null-annotations.
> >
> > An example of why this is a bad idea is depending on
> > com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar's @Nonnull,
> > which, in the current version Eclipse at least shows up as an illegal
> > annotation when you use it, defeating the purpose: "Annotation types
> > that do not specify explicit target element types cannot be applied
> > here Objects.java
> > /commons-lang3/src/test/java/org/apache/commons/lang3/function line 74
> > Java Problem"
> >
> > Gary
> >
> > >
> > > If my method needs arguments that are not null than I have to check them
> > > and throw an exception if the caller of the method tries to pass NULL
> > > into it. If I'm too lazy to check my parameters than I deserve it to get
> > > NPE e.g. (funny enough an external coder with 20+ years of experience at
> > > my work just experience that exactly now, as he just relies that
> > > everything is always there...).
> > >
> > > Am 11.02.2024 um 22:27 schrieb Benjamin Marwell:
> > > > Hello devs and plugin maintainers!
> > > >
> > > > Since JSR 305 (Nullable annotations etc.) did not get implemented
> > > > officially, and Maven allows `null` in a lot of locations, I wanted to
> > > > ask about your opinions about using jspecify: https://jspecify.dev/
> > > >
> > > > JSpecify was created by the Java community (i.e. Java decs but also
> > > > larger corporations like Google, if I am not mistaken. It was seen as
> > > > needed since JSR 305 never materialized and probably never will.
> > > > Google hat a Guava Situation [1] and decided to do something about it.
> > > >
> > > > JSpecify says it is safe to adopt it [2]. Although the current version
> > > > is 0.3, it is more like 0.9.
> > > >
> > > > I honestly think that Maven would benefit from those annotations, as
> > > > many recent libraries try to avoid `null` as best as they can. Younger
> > > > developers may not be used to seeing nullable parameters, and even
> > > > some of us don't know which parameters can be nulled (or not).
> > > >
> > > > Let me know what you think about this idea.
> > > >
> > > > My personal opinion: I am pretty confident jspecify will displace
> > > > checker-qual as the "top dog" of nullness annotations in the future. I
> > > > also want to give plugin authors a way to use null in their plugins,
> > > > too, although we could make it an optional dependency (just
> > > > annotations...).
> > > >
> > > > Looking forward to reading your opinions!
> > > >
> > > > - Ben
> > > >
> > > > 1: https://github.com/google/guava/issues/2960
> > > > 2: https://github.com/jspecify/jspecify/wiki/adoption
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [email protected]
> > > > For additional commands, e-mail: [email protected]
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to