Community
Participate
Working Groups
JDT's analysis offers nice NullPointer analysis capabilities. I wonder how difficult it is to check whether a method may return null - or a parameter needs to be @Nonnull or @Nullable. Stephan, that's likely your domain? I'm still interested to collect these annotations by some kind of crowd-sourcing for libraries (which are not source projects in the workspace). But generally having above analysis capabilities + quick assist would be a great basis for other steps.
(In reply to Marcel Bruch from comment #0) > JDT's analysis offers nice NullPointer analysis capabilities. I wonder how > difficult it is to check whether a method may return null - or a parameter > needs to be @Nonnull or @Nullable. You are not asking for a quick *fix* to mend an existing error/warning, but for s.t. like "infer null annotations" applied to the signature of a given method, right? Perhaps we could just perform a flow analysis run with optimistic annotations inserted, like: marking all parameters as @Nullable and the return type as @NonNull. If that triggers any problems the annotations may have to be inverted ... I'm not sure, though, how many combinations of annotations that inference would have to try. We also have to be careful about situations where neither annotation can be conclusively inferred. Sounds like an interesting project, so let's see what we can do ...
(In reply to Stephan Herrmann from comment #1) > You are not asking for a quick *fix* to mend an existing error/warning, but > for s.t. like "infer null annotations" applied to the signature of a given > method, right? Yes. But I'd like to use this "headless" as well to run large-scale offline analyses of, e.g., the simrel repo. > Perhaps we could just perform a flow analysis run with optimistic > annotations inserted Makes sense. It would be great if external information could be leveraged as well. If we manage to build a crowd-sourcing system around this, we could incorporate (yet) external knowledge to the analysis. > Sounds like an interesting project, so let's see what we can do ... If you are able to provide a headless implementation, I'd run it on the Mars repo and share the results.
I will first focus on individual quick assists, where we still know that a user is watching what's happening - so we don't just blindly trust the new inference. Note that some tools already exist, which (claim to) provide the fully automatic analysis of entire libraries as you request. See, e.g., the tools linked here: http://wiki.eclipse.org/JDT_Core/Null_Analysis/External_Annotations#References If any of those tools prove useful for the task, I will write a little importer from their output to our .eea.
(In reply to Stephan Herrmann from comment #1) > (In reply to Marcel Bruch from comment #0) > > JDT's analysis offers nice NullPointer analysis capabilities. I wonder how > > difficult it is to check whether a method may return null - or a parameter > > needs to be @Nonnull or @Nullable. > > You are not asking for a quick *fix* to mend an existing error/warning, but > for s.t. like "infer null annotations" applied to the signature of a given > method, right? Note that in our Eclipse world the API i.e. Javadoc defines the contract, hence inferring it from the source code would be wrong.
That's even better, inferring it from the Javadoc(1) should be much easier :) 1) Seeing "@return|@param <name>" ... "or null" means it's @Nullable, otherwise it's @NonNull(2). 2) @throws can be ignored as it just tells what happens if the contract isn't honored.
Ran out of time for 4.7. Bulk move to 4.8.
Rephrased the summary to reflect our discussion.
.
