[
https://issues.apache.org/jira/browse/LOG4J2-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17536880#comment-17536880
]
Matt Sicker commented on LOG4J2-1477:
-------------------------------------
Found this issue recently again. The [Checker
framework|https://checkerframework.org/] is a pretty good choice from what I've
read.
As for Java 8 type annotations, note that the DI system in 3.x takes advantage
of type annotations as an inline way of defining a {{Key<T>}} instance for a
type that also needs an annotation on it. For example, {{PluginManager}}
instances are qualified by the name of their respective plugin category, and
given a static {{String}} constant {{CATEGORY}} in the class, then a
{{Key<PluginManager>}} instance can be defined inline like so:
{code:java}
Key<PluginManager> PLUGIN_MANAGER_KEY = new @Named(CATEGORY) Key<>() {}; {code}
(Note that in Java 8, the right side doesn't infer the {{PluginManager}} type
and needs to be written explicitly. Java 11 has better type inference for
generics.)
As for how this relates to nullability annotations and type annotations? Well,
if a {{Key<T>}} (or the internal class {{{}InjectionPoint<T>{}}}) could track
the nullability of the type it's keyed on, then we can ensure better
null-safety when injecting things. These are loosely related to constraint
validators, so they could even be supported at runtime through that, though
this would be similar to supporting {{Optional<T>}} injection as requested in
LOG4J2-3496 and assuming non-null otherwise, but this doesn't mesh well with
the existing behavior that all the existing plugin annotations assume things
are nullable (other than the newly added {{@Inject}} stuff which assumes
non-null, but that could be changed for consistency). Either way it's done, it
would be nice for static code analysis to match runtime behavior. And IntelliJ
has some nullability inference that can fill out some of the nullability
annotations robotically.
> @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ć
> Priority: Major
>
> 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.7#820007)
