As I see it, the annotations serve two purposes. They clarify for the users
where nulls are legal values, and they allow development tools to leverage
the information to provide more detailed inspections. Some colleagues have
objected to their use claiming that, we don't want to rely on a specific
tool. I've never understood this logic, because we don't actually rely
on the code inspections. The code works either way. The annotations do no
harm, and they often help. That said, I'm glad there's an Eclipse plugin,
even though I don't use Eclipse. (Somehow, they never apply their argument
to tools like FindBugs, even though that uses annotations too.)

IDEs aside, a lot of developers have been using Optional to solve the
problem of null parameters and return values, and it's producing some very
bad code. If anything, simply by specifying in the API where null values
are allowed will do a lot to clarify how APIs should be used. If this
improves the quality of people's code, they will have served their purpose,
regardless of what inspections are used.
— Miguel Muñoz



On Fri, Aug 28, 2020 at 10:15 AM Xeno Amess <xenoam...@gmail.com> wrote:

> https://imgur.com/gGRHH5i
> https://imgur.com/THMdel1
> 😊
>
> Xeno Amess <xenoam...@gmail.com> 于2020年8月29日周六 上午12:46写道:
>
> > https://imgur.com/gGRHH5i
> > https://imgur.com/THMdel1
> > will try imgur
> >
> > Gary Gregory <garydgreg...@gmail.com> 于2020年8月29日周六 上午12:44写道:
> >
> >> The PNG links yield Temporary Error (404).
> >>
> >> Gary
> >>
> >> On Fri, Aug 28, 2020 at 12:31 PM Xeno Amess <xenoam...@gmail.com>
> wrote:
> >>
> >>> @Gary Gregory <garydgreg...@gmail.com>
> >>> the outcome is:
> >>> Eclipse users CAN use those annotations, but MUST install a
> >>> eclipse-plugin to detect those bugs and show them on screen.
> >>> (though both idea and eclipse users CAN choose to use maven plugin to
> do
> >>> it lol)
> >>>
> >>> The plugin is:
> >>> eclipse_2020-08-29_00-28-02.png
> >>> (14 K)
> >>>
> >>> <
> https://mail.google.com/mail/u/0?ui=2&ik=40323997ff&attid=0.1&permmsgid=msg-a:r-2567034696490897823&view=att&disp=safe&realattid=f_keegbc8a0
> >
> >>>
> >>>
> >>> and the outcome gui page is:
> >>> eclipse_2020-08-29_00-30-29.png
> >>> (236 K)
> >>>
> >>> <
> https://mail.google.com/mail/u/0?ui=2&ik=40323997ff&attid=0.2&permmsgid=msg-a:r-2567034696490897823&view=att&disp=safe&realattid=f_keegd69v1
> >
> >>>
> >>>
> >>> Well, it seems at least usable :)
> >>>
> >>> Xeno Amess <xenoam...@gmail.com> 于2020年8月28日周五 下午11:08写道:
> >>>
> >>>> >  Keep in mind that not everyone uses IJ, for example, I use Eclipse.
> >>>> Yep.
> >>>> And not every jetbrains library requires people use idea.
> >>>> I think Eclipse can supports those annotations.
> >>>> Let me, have a test :)
> >>>>
> >>>>
> >>>> Gary Gregory <garydgreg...@gmail.com> 于2020年8月28日周五 下午11:04写道:
> >>>>
> >>>>> Keep in mind that not everyone uses IJ, for example, I use Eclipse.
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>> On Fri, Aug 28, 2020 at 10:54 AM Xeno Amess <xenoam...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> > >  IntelliJ specifies Runtime retention so they can interact
> >>>>> > with IntelliJ's internal JRE, which adds additional assertions into
> >>>>> the
> >>>>> > code to enforce the annotations.
> >>>>> >
> >>>>> > seems never.
> >>>>> > see this demo repo.
> >>>>> > https://github.com/XenoAmess/demo_jetbrains_annotation
> >>>>> >
> >>>>> > And I looked up the sources and see every annotation classes be
> >>>>> > with RetentionPolicy.CLASS or RetentionPolicy.SOURCE
> >>>>> >
> >>>>> > HOWEVER, I was talking about org.jetbrainss.annotations.
> >>>>> > but for jsr305, which is google java codes, I will not be very
> >>>>> surprised if
> >>>>> > they have different ideas.
> >>>>> >
> >>>>> > Miguel Muñoz <swingguy1...@gmail.com> 于2020年8月28日周五 下午1:54写道:
> >>>>> >
> >>>>> > > Good question. IntelliJ specifies Runtime retention so they can
> >>>>> interact
> >>>>> > > with IntelliJ's internal JRE, which adds additional assertions
> >>>>> into the
> >>>>> > > code to enforce the annotations. So even though they have Runtime
> >>>>> > > retention, they're still a development-phase tool. In production,
> >>>>> they
> >>>>> > > don't need to be retained at runtime. Personally, I never need
> the
> >>>>> > Runtime
> >>>>> > > retention feature, so if we write our own annotations, we can
> give
> >>>>> them
> >>>>> > > compile-time retention and they'll work fine. That's often how I
> >>>>> work. In
> >>>>> > > fact, I often use my own annotations, which don't have Runtime
> >>>>> retention,
> >>>>> > > and they work fine, so I don't miss that feature.
> >>>>> > >
> >>>>> > > — Miguel Muñoz
> >>>>> > >
> >>>>> > > On Tue, Aug 25, 2020 at 12:36 PM 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
> >>>>> > > >
> >>>>> > > >
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
>

Reply via email to