Bug 538875 - [null] Annotation-specific editor/browser for annotated types
Summary: [null] Annotation-specific editor/browser for annotated types
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.8   Edit
Hardware: PC Windows 10
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 466299
Blocks:
  Show dependency tree
 
Reported: 2018-09-10 11:11 EDT by Ed Willink CLA
Modified: 2018-09-11 01:32 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2018-09-10 11:11:30 EDT
From Bug 414237

Using the JDT editor on a class with non-null annotations, F3 on a declaration with external annotations should open a 'read-only' editor/viewer somewhat like the class file viewer.

This editor/viewer should render the external non-null annotations in traditional @NonNull form.

This editor/viewer should be titled to clarify that the editor/viewer is for a class X viewed from the annotation path of bundle Y.

It would be nice if the editor/viewer used a distinctive case/font/color for the contributions of the external annotations. Perhaps everything other than the external annotations is partially greyed out.

It would be nice if the editor/viewer permits the external annotations to be edited.

It would be nice if the editor/viewer provides navigation to related editors/viewers for the same class viewed from other annotation paths.

It would be nice if the hovertext for an external @NonNull identified the annotation path entry that contributed it.
Comment 1 Ed Willink CLA 2018-09-10 11:16:43 EDT
(In reply to Ed Willink from comment #0)
> From Bug 414237

Correction: from Bug 466299#c22
Comment 2 Stephan Herrmann CLA 2018-09-10 17:26:59 EDT
Wouldn't implicit annotations (inherited, from @NonNullByDefault, or from external annotations) make a wonderful use case for code mining?
Comment 3 Ed Willink CLA 2018-09-11 01:32:41 EDT
FYI. I never use @NonNullByDefault since I cannot tolerate the risks that will occur in the perhaps 1% of legacy usage where @Nullable is appropriate. Equally I find secret declarations inherently dangerous/confusing.

(Until the platform and EMF are @NonNull'd, all my code has to be legacy compatible.)

I see a number of 'source synthesis' bugs whereby my explicit @NonNull gets doubled up. Waiting for more important bugs to fix up first.