Community
Participate
Working Groups
Created attachment 250764 [details] draft proposal This is a heads-up regarding work currently done in JDT as documented in https://wiki.eclipse.org/JDT_Core/Null_Analysis/External_Annotations In a nutshell: we want to support separate definitions of null annotations for 3rd party libraries, such that the compiler's null analysis can take these external annotations into account. This is until now the major missing link towards provably NPE-free programs. I'm filing this bug against PDE, because I think that users should be able to attach external annotations individually for each referenced plugin. Attaching external annotations happens via an extra attribute on a classpath entry. For plugin development, however, there is basically only one raw classpath entry: the requirePlugins container. Adding the new attribute to the requiredPlugins container would require to collect all external annotations in one big pile. If attachment should be possible per plugin, JDT will need some information back from PDE. I have a sketch, where all we'd need from PDE is adding a well-known classpath attribute to each resolved classpath entry it creates. This attribute shall be used to uniquely identify each plugin / version in order to map it to a corresponding package of external annotations. The value of that attribute might simply be symbolicName_major.minor.micro (we wouldn't want .qualifier to ensure minimal stability of names). The approach is intended to work with other classpath containers, like m2e's container, too. The corresponding bug in JDT/Core land has a little more explanation: bug 459753. The proposed change itself is actually a no-brainer, but it creates a new kind of API that both sides have to agree upon. If anybody has other ideas how to tell JDT minimal information about each individual plugin referenced via requiredPlugins, please let me know.
With blocking bug 459753 deferred to 4.6 there's currently nothing we can do here.
(In reply to Stephan Herrmann from comment #1) > With blocking bug 459753 deferred to 4.6 there's currently nothing we can do > here. Bug 459753 moved to 4.7
Stephan, is this ( and corresponding Bug 459753 ) still in plan for 4.7?
(In reply to Vikas Chandra from comment #3) > Stephan, is this ( and corresponding Bug 459753 ) still in plan for 4.7? Hi Vikas, you did the right thing in pulling this bug off the schedule. A pity, but other work had priority during 4.7.
