Le mer. 26 août 2020 à 08:42, Xeno Amess <xenoam...@gmail.com> a écrit :
> > how do we guarantee our meta are right and don't create false positives > If we cannot even make the meta correct, then means we cannot make sure > which function can return Null, which can not, > Then why do you think our customers can do. > Because it is validated as mentioned and report errors/warnings (or even fail the build). So my point is if we want to go that path, which validation do we add to ensure it is correct (we can use tests to have calling code for that) - else we should skip that feature and replace it by either an external descriptor (saw some XML around that kind of feature) or just static analysis tools which do exactly the same work without any meta (@Null/@NotNull is mainly about making the validation feedback faster by shortcutting code path analysis and/or validating spec vs impl, not just providing meta static analysis tools already have to make it clear). > And if people who write these libs are not sure which function can > receive Null parameters, sounds like adding it will at least make > developers sure their logics. > > Romain Manni-Bucau <rmannibu...@gmail.com> 于2020年8月26日周三 下午2:30写道： > > > For what it is worth: > > > > 1. Generally speaking - and IMHO - these annotations only make sense in a > > particular tooling setup(s) - like considering values which can be null > by > > code analysis and not by spec (@NotNull) - which I'm not sure we have so > it > > is mainly about making it consumer friendly but how do we guarantee our > > meta are right and don't create false positives? Until we can guarantee > it, > > it sounds like we can only bring drawbacks by adding it and users can > > trivially solve it since if he already uses @NotNull he puts it in his > code > > at a higher level anyway. > > 2. Please don't use javax.annotation.* since, thanks JPMS, it can make > the > > code not compilable on java >= 9 - a package must be owned by a single > > module. (Not)Nullable static check is generally about the annotation > > simple name and not the package so you can just duplicate the 1-2 > > annotations you want in [lang], it is a saner compromise in today's > > ecosystem. > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > Le mer. 26 août 2020 à 01:30, Matt Sicker <boa...@gmail.com> a écrit : > > > > > Runtime retention still doesn’t require the annotations to be present > on > > > the classpath unless you perform reflection on them (I forget the > > > specifics). It’s a feature specific to annotations. > > > > > > On Tue, Aug 25, 2020 at 14:36 Jochen Wiedmann < > jochen.wiedm...@gmail.com > > > > > > wrote: > > > > > > > On Tue, Aug 25, 2020 at 9:08 PM sebb <seb...@gmail.com> wrote: > > > > > > > > > > > > > > > > > AFAIK that means Maven won't download the dependency. > > > > > > > > > Surely that makes it harder for the developer? > > > > > > > > > > > > > > > > No, it means that Maven won't add the dependency to a distribution. > > > > > > > > > > > > > > > > However, I've got a question: These annotations have > > > > > > > > @Retention(Runtime). (See > > > > > > > > > > > > > > > > > > https://www.javadoc.io/doc/com.google.code.findbugs/jsr305/latest/javax/annotation/Nullable.html > > > > .) > > > > > > > > Aren't we enforcing the presence of the respective jar at runtime? > > > > > > > > > > > > > > > > > > > > > > > > Jochen > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Look, that's why there's rules, understand? So that you think before > > > > > > > > you break 'em. > > > > > > > > > > > > > > > > -- (Terry Pratchett, Thief of Time) > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > -- > > > Matt Sicker <boa...@gmail.com> > > > > > >
