Community
Participate
Working Groups
When using @NonNullByDefault for only some parts of the code, it is not trivial to see what the effective specification of any given method is. Any parameter without a null annotation could either be affected by the default or be unspecified if outside the scope of the default. It would be great if the UI could somehow visualize the "effective" specification, i.e., after applying any defaults. I suggested to do this in the hover. @Markus: when we discussed this I remember you mentioned bug 357325 and seeing this resolved is great. But I don't remember if we came to a conclusion regarding the "effective" specification from a default. Let me know if JDT/Core should surface the implicit annotations in either model or DOM.
I just stumbled upon a project that seems to subclass SourceViewerDecorationSupport for a similar purpose: drawing overlays that indicate results of some semantic inference right in the editor. Having a little "!" (nonnull) or "?" (nullable) superscript on type references would be really cool :) Yet I assume, printing something into the (javadoc) hover is probably much more straight-forward.
Marking as duplicate, because the proposed solution in the other bug already covers this request, too. *** This bug has been marked as a duplicate of bug 403917 ***
While indeed bug 403917 significantly improves the situation, it doesn't yet help for declaration annotations. The existing solution can be extended for "old" null annotations by: JDT/Core: (1) letting MethodBinding (DOM) materialize implicit null annotations into IAnnotationBindings (the compiler binding has all information we need) JDT/UI: (2) prepending a null annotation to the binding label. I tried to implement (1) restricted to certain call graphs (e.g., only clients of ASTParser.createBindings()), but found that this is likely to create inconsistencies, rather than improve anything. Change (2) is needed because declaration annotations on the method are still discovered only via the IJavaElement (only the label / signature is driven by bindings). I think rendering a @NonNull/@Nullable on a method as part of the signature improves usability anyway. These two changes improve the user experience regarding all of: - @NonNullByDefault - external annotations - inherited annotations (if that option is enabled) making the recent achievements regarding TYPE_USE annotations available also for declaration annotations.
New Gerrit change created: https://git.eclipse.org/r/47727
Created attachment 253410 [details] UI part concerning part (2) (In reply to Eclipse Genie from comment #4) > New Gerrit change created: https://git.eclipse.org/r/47727 The gerrit change contains the Core part regarding (1). The UI part for (2) has a new test which cannot succeed without the Core part, hence I'm attaching this as patch.
(In reply to Stephan Herrmann from comment #5) > Created attachment 253410 [details] > UI part concerning part (2) > > (In reply to Eclipse Genie from comment #4) > > New Gerrit change created: https://git.eclipse.org/r/47727 > > The gerrit change contains the Core part regarding (1). I've uploaded an extended version that considers the fact that implicit null annotations are initialized on demand. > The UI part for (2) has a new test which cannot succeed without the Core > part, hence I'm attaching this as patch. This part remains unchanged (see attachment 253410 [details]).
Sorry for the delay. I have reviewed the JDT Core part and looks good to me.
This will not qualify for an RC2 rebuild. Moving to RC3 but this might be moved out of 4.5.
Sorry, I think it's too late for adding this feature. Furthermore, I have some reservations against the changes: The IMethodBinding#getParameterAnnotations(int) and IBinding#getAnnotations() APIs clearly specify that they only return declaration annotations that are specified on the given element. Returning implict null-related type annotations violates those specifications. In the UI, I think the implicit annotations should look a bit different from annotation that are actually declared on the element.
(In reply to Markus Keller from comment #9) > The IMethodBinding#getParameterAnnotations(int) and > IBinding#getAnnotations() APIs clearly specify that they only return > declaration annotations that are specified on the given element. Returning > implict null-related type annotations violates those specifications. This seems to leave us with two options: (1) add new API, s.t. like IMethodBinding#getImplicitParameterAnnotations(int) and IBinding#getImplicitAnnotations(), or (2) tell users that support for declaration null annotations is in maintenance mode, no new features will be added here. Any preferences?
no further action planned, atm.
(In reply to Stephan Herrmann from comment #10) > (2) tell users that support for declaration null annotations is in > maintenance mode, no new features will be added here. de-facto that's what's happening (unless someone is keen on working on this).
