[
https://issues.apache.org/jira/browse/LOG4J2-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788345#comment-17788345
]
Greg Thomas commented on LOG4J2-1477:
-------------------------------------
> I can make some aliases in the API to make this simpler to update later on if
> needed.
So yet another Nullable annotation to add to the list at
[https://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use]
? The Log4J one?
It seems to be that perhaps (perhaps) [https://jspecify.dev/] is the way to go.
Certainly something I'm keeping an eye on, and seems to have backing from some
big players - https://jspecify.dev/about
Though of course [https://xkcd.com/927/] applies I guess.
> @NonNull support (for @NonNullByDefault or similar)
> ---------------------------------------------------
>
> Key: LOG4J2-1477
> URL: https://issues.apache.org/jira/browse/LOG4J2-1477
> Project: Log4j 2
> Issue Type: Wish
> Components: API
> Affects Versions: 2.6.2
> Environment: any
> Reporter: Bojan Antonović
> Assignee: Matt Sicker
> Priority: Major
> Fix For: 3.0.0
>
>
> Eclipse (and other tools) offer non-null checks by annotation processing.
> One of the possibilities to enable this is to add the annotation
> @org.eclipse.jdt.annotation.NonNullByDefault in your package-info.java file.
> Example:
> @org.eclipse.jdt.annotation.NonNullByDefault
> package foo;
> A frequent problem is reported when using a logger:
> private static final Logger LOGGER = LogManager.getLogger(Bla.class);
> for which Eclipse says:
> Null type safety (type annotations): The expression of type 'Logger' needs
> unchecked conversion to conform to '@NonNull Logger' Bla.java (...)
> This can by bypassed by putting a @SuppressWarnings("null") over the
> expression, but this has to be done in every class, and may be the *only*
> line of code with this workaround.
> Problems:
> - There are other annotations for non-null (javax.annotation.Nonnull) and
> many other frameworks, like the Checker Framework.
> - I don't want to be a judge which one to choose.
> - Deeper support may require a dependency on Java 8.
> - If you want to do it framework wide, this can be a huge task.
> - As some tools are not mature (IMHO), it will need experiments.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
