Let's get back on topic here please: What I'm looking for is what the
JAVADOC should say, in words, to set expectations for users/call sites and
provide guidance for implementors.
What matters more is what null means when it's allowed because telling me
something is nullable with an annotation is useless without an explainer
IMO.
Gary
Gary
On Wed, Oct 16, 2024, 12:27 PM sebb <seb...@gmail.com> wrote:
> On Wed, 16 Oct 2024 at 16:15, Gary Gregory <garydgreg...@gmail.com> wrote:
> >
> > I don't think we need this, mostly because I prefer to not have issues
> with
> > annotation X vs. Y vs. Z. There are a ton of these types of annotations
> out
> > there and using one vs another because the Jetbrain IDE likes it is not a
> > good enough reason IMO. There's also a javax version, and a jakarta
> > version, and so on. Then there is the retention issue, and which one to
> > pick and why, which then brings you to who really is the client for
> these,
> > the source maintainer? The IDE tooling? A runtime framework? I'd rather
> > skip all of it until it becomes a requirement.
>
> Agreed.
>
> We certainly don't want annotations that create a runtime dependency.
>
> > Gary
> >
> > On Wed, Oct 16, 2024, 9:50 AM Claude Warren <cla...@xenei.com> wrote:
> >
> > > What is the general stance on commons to import the annotations? Is
> there
> > > a reason not to? I'm happy to make the changes but want to make sure
> there
> > > is not a blocker first.
> > >
> > > Claude
> > >
> > > On Tue, Oct 15, 2024 at 9:56 AM Xeno Amess <xenoam...@gmail.com>
> wrote:
> > >
> > > > yep, I always think, this kind of allow null not allow null things
> shall
> > > be
> > > > marked not by doc, but by annotations.
> > > >
> > > > Xeno Amess <xenoam...@gmail.com> 于2024年10月15日周二 04:10写道：
> > > >
> > > > > 1. important jetbrains annotations as maven dependency.
> > > > > 2.add @Nullable in parent class's param
> > > > > 3.add @NotNull at child class param
> > > > >
> > > > > ------------------------------
> > > > > *From:* Gary D. Gregory <ggreg...@apache.org>
> > > > > *Sent:* Tuesday, October 15, 2024 3:29:20 AM
> > > > > *To:* dev@commons.apache.org <dev@commons.apache.org>
> > > > > *Subject:* [CLI] Javadoc
> > > > >
> > > > > Hi All,
> > > > >
> > > > > We now have append methods like:
> > > > >
> > > > > public interface HelpAppendable extends Appendable {
> > > > >
> > > > > /**
> > > > > * Appends a header.
> > > > > *
> > > > > * @param level the level of the header. This is equivalent to
> the
> > > > > "1", "2", or "3" in the HTML "h1", "h2", "h3" tags.
> > > > > * @param text the text for the header
> > > > > * @throws IOException on write failure
> > > > > */
> > > > > void appendHeader(int level, CharSequence text) throws
> IOException;
> > > > >
> > > > > ...
> > > > >
> > > > > The supertype defines behavior for null input, but here we do not,
> we
> > > > > should either document it as:
> > > > > - Same as the super type, same kind of Javadoc
> > > > > - Explicitly document that it is up to the implementing class
> > > > >
> > > > > Thoughts?
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > LinkedIn: http://www.linkedin.com/in/claudewarren
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
