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

JSR-305 Support #575

Open
grabstepango opened this issue Jan 4, 2018 · 3 comments

Comments

@grabstepango
Copy link

commented Jan 4, 2018

AutoValue have @nullable support which is great. But what about other JSR-305 capabilities.
For example, I could define annotation like

@Documented
@Nullable
@TypeQualifierDefault(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE)
public @interface MethodsReturnNullableByDefault {}

To remove repetitive @nullable annotations for POJO's
This annotation will work perfectly with many tools which have JSR-305 support but AutoValue will still generate guard checks for nulls which will behave inconsistently with lint/IDE checks.

@ronshapiro

This comment has been minimized.

Copy link
Contributor

commented Jan 5, 2018

JSR 305 was never actually accepted and it's status in a Java 9/JPMS world is even more complicated. I don't think it makes sense to add support for something that is non-standard but I'll leave that call to @eamonnmcmanus.

It's also worth considering this against other nullness libraries such as the checker framework. Which (if any) of all of the nullness frameworks should we support?

Perhaps something in AutoCommon could be contributed to determine if an element is nullable, and that can handle all of the common cases without forcing libraries to think about that. But that may be too far of a net to cast.

@JakeWharton

This comment has been minimized.

Copy link
Member

commented Jan 5, 2018

Moreover, checker has the advantageous property of defaulting to non-null which is what auto value assumes by default as well.

@eamonnmcmanus

This comment has been minimized.

Copy link
Contributor

commented Jan 6, 2018

AutoValue doesn't depend on JSR 305. If you have an annotation called @Nullable it will be recognized regardless of what package it appears in. The idea being that there are several well-known packages that define a @Nullable annotation, and they all mean the same thing. You can also define your own, and we'll assume you mean the same thing as everyone else.

If the question is specifically about @MethodsReturnNullableByDefault then I'm not so sure. That's not the name of a well-known annotation, is it? Is there some other annotation that would mean the same thing? I see some people use @MethodsReturnNonnullByDefault, but that's already the default in AutoValue. It's also not part of JSR 305.

@raghsriniv raghsriniv added the P3 label Jun 24, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.