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

Explicitly indicate Nullability of arguments and return values #1105

Open
k163377 opened this issue Sep 9, 2023 · 4 comments
Open

Explicitly indicate Nullability of arguments and return values #1105

k163377 opened this issue Sep 9, 2023 · 4 comments

Comments

@k163377
Copy link

k163377 commented Sep 9, 2023

Currently nullability is not explicitly stated for Jackson.
On the other hand, there are actually APIs that do not allow null input.
Also, there are cases where inadvertent destructive changes can occur, as in the issue submitted below.
FasterXML/jackson-dataformat-xml#607

Personally, I think that Nullability annotations should be given to public interfaces to avoid such problems.
Jackson is a huge project and we cannot fix everything at once, but I think we can proceed gradually.

There are several possible annotations to use, but to minimize the impact, it is better to choose one whose RetentionPolicy is not RUNTIME.

@cowtowncoder
Copy link
Member

The main problem here is that I really do not want to add a dependency to external annotations package. If JDK provided annotation with Java 8, I'd be happy to add those, but otherwise not.

@k163377
Copy link
Author

k163377 commented Sep 20, 2023

Unfortunately, as far as I know, JDK does not provide such annotations.
I think adding external packages is the easiest and most effective way.

I agree that external packages should not be added thoughtlessly.
However, there are significant advantages to implementing it, both in terms of convenience and maintainability.
I also believe that the impact can be minimized if the RetentionPolicy is not RUNTIME.

Alternatively, we could introduce our own annotations, although support by the IDE would be weaker.

@cowtowncoder
Copy link
Member

If it was possible to have combination of not-RUNTIME retention and scope of provided (so downstream would not require dependency), maybe I'd go with that.

For now I don't think I want to add these annotations here.
Will leave the issue open in case my mind changes.

@k163377
Copy link
Author

k163377 commented Sep 23, 2023

If it was possible to have combination of not-RUNTIME retention and scope of provided

JetBrains Java Annotations seems to be able to meet this requirement.
https://mvnrepository.com/artifact/org.jetbrains/annotations
https://github.com/JetBrains/java-annotations/blob/ac4b67f071bef18abd4f9c8e7fe1a8d2a861dddf/common/src/main/java/org/jetbrains/annotations/NotNull.java#L28

I will share how I used jOOQ-meta with Intellij as an example.
https://github.com/jOOQ/jOOQ/blob/54d663bcba6a30e58c10a87a6715a6dbeb42bf16/jOOQ-meta/pom.xml#L51-L56

The return value of the getNamespace method is annotated as NotNull, but if define it to return null, a warning is displayed(not compile error).
image

The NotNull annotation is not bundled with the dependencies and is not available unless added.
image

A sample project is uploaded below (requires Java 17).
maven-java-sandbox.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants