Community
Participate
Working Groups
M5. I've been getting consistent trouble with wrong @NonNull annotation diagnostics. These have got worse with the introduction of the not-designed-for infos for which I have accurate manual annotation for e.g. Map.get(). I have some files that stubbornly report warnings that I know to be wrong. e.g. aList = aMap.get(...) if (aList != null) { ... } insists that aList cannot be null. Restarting Eclipse usually makes the diagnostics go away. These rubbish diagnostics are benign but irritating since I have to ignore them undermining the ones I should not ignore. I think that the problem stems from the inadequate transitive scoping of the definitions. I have two projects. One shares all its annotations in one common location. There is no mechanism for another dependent project to import the first (from its JAR) so it has to repeat all the annotations in a second common location. I suspect that when Map.java is opened from one project group, it acquires annotations from that project and this inhibits the annotations from another project. Worse if Map.java is opened from a non-annotations project, annotations get corrupted. Potentially the annotations on Map.java may be different for each consuming plugin; an understandable nightmare for JDT tooling. An import capability would eliminate many accidental conflicts, but the nightmare seems unavoidable. Worse, if a declaration has one set of annotation files, and an override has a different set of annotation files, the two must be merged.
Ed, to me this looks exactly like bug 466299. Do you agree? For a while I had great hope that we could resolve this via bug 497513 but after work on the new index stalled, I don't have a viable plan at hand :( So, for external annotations for JRE there was this recommendation to use just one workspace setting. If that doesn't fit your needs, you could ask on https://mattermost.eclipse.org/eclipse/channels/jdt-null-analysis if s.o. found a way to avoid this problem in a manner that also works for you. *** This bug has been marked as a duplicate of bug 466299 ***
(In reply to Stephan Herrmann from comment #1) > So, for external annotations for JRE there was this recommendation to use > just one workspace setting. As noted on Bug 466299: IMHO anything that relies on a workspace setting to make project functionality correct guarantees that two users collaborating via a GIT repo for their project get confused. It must be possible to have explicit project settings that make the correct operation of one project independent of other projects.
