Community
Participate
Working Groups
from bug 364815 comment #17: > More generally: in the core we decided to not perform any lookup of > configured annotation types before they are actually used in the code. > > Since the UI doesn't do any validation either (I understand this would only > work on the project level) users can now break null-analysis by a simple > typo in the preferences without being alerted. > > Maybe we should rethink responsibility for a desirable validation here. > Unqualified names are really just a special case that was relevant for the > implementation at some point but doesn't require special treatment any longer. > The problem is: user specifies in the preferences: org.mycomp.Nonnull and > writes code using @org.mycomp.NonNull and still gets no errors/warnings. Initial idea: maybe we can lookup/check annotation types on each full build while keeping the lazy strategy for incremental builds. In that case we'd need to make errors against that configuration distinguishable from normal compiler errors to avoid their deletion during incremental build.
I think we also have to revisit the JavaCore.COMPILER_*_ANNOTATION_NAME options. The current API doesn't allow using only one of the nullness annotations, but NonNullByDefault may not even be supported by all sets of nullness annotations. The APIs should also allow the empty string if the given annotation kind is not used.
(In reply to comment #1) > I think we also have to revisit the JavaCore.COMPILER_*_ANNOTATION_NAME > options. The current API doesn't allow using only one of the nullness > annotations, but NonNullByDefault may not even be supported by all sets of > nullness annotations. The APIs should also allow the empty string if the given > annotation kind is not used. For NonNullByDefault I definitely agree. Currently, any string that doesn't match an existing annotation type would do, but if we start validating the string, users must be able to explicitly opt-out. Doing without NonNull or Nullable looks less useful to me. I haven't seen a set of null annotations without either of these. The implementation actually requires NonNull to exist, currently.
We should also make sure the same annotation is not used for two different purposes i.e. if @NonNull is used as both non-null and non-null-by-default annotaion, the UI dialog should give an error.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
