eclipse-ocl-bot
commented
1 day ago By Ed Willink on Jun 06, 2020 03:23
The problem with external annotations is that the original declaration is tweaked zero or more times by tweaks that may not be consistently visible to tooling and consequently tooling may easily neglect to respect the tweaks (which could be conflicting or even wrong). Another problem is that the *.eea files are only semi-readable.
If we instead use wrappers, there is a consistent outer declaration that all tooling should use without difficulty and which is available for access from installed plugins and is even available for use in inheritance hierarchies of wrapper classes.
Since the wrappers are thin static functions, one might hope that JIT will see them as final and optimize them away. A static function can be declared final so adding final should do no harm; it might even encourage JIT.
Just need a consistent naming policy.
?? java.lang.Class.getName is wrapped by AnnotationWrappers.Class_getName(Class) ??
overloading may avoid the need for extended package qualification for clashes.
| --- | --- | | Bugzilla Link | 564014 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 06, 2020 02:55 EDT | | Modified | Jan 12, 2021 12:34 EDT | | See also | 414237, 509397, 462412, 486868, 526011, 569379 | | Reporter | Ed Willink |
Description
Bug 414237#c28 provides the very sad news that Stephan Herrmann is leaving JDT. Since he was perhaps solely responsible for the Bye Bye NPE initiative we must reassess use of @NonNull / @Nullable annotations now that they move from a secondary priority of a primary committer to perhaps an embarrassment for the residual committers struggling to implement the incessant sequence of next-Javas.
Clearly none of the outstanding bugs regarding external annotations will be fixed. Potentially the embarrassment may be categorized as not-JLS and just deprecated wholescale.
What do @NonNull / @Nullable do for us (we never yse @NonNullByDefault)?
1) Provide formal documentation of interface design intent 2) Synchronize interface design intent over an inheritance hierarchy 3) Provide stronger null hazard analysis with functions 4) Identify redundant null checks within functions
But @NonNull / @Nullable do not help and sometimes even fail when a function from an unannotated project is used.
5) Support provision of annotations for unannotated functions
what would we do if there was no @NonNull / @Nullable / we deleted them all?
1) We have to add numerous informal Javadoc comments for the intent.\ -- too painful, we refactor org.eclipse.jdt.annotation.NonNull as org.eclipse.ocl.annotation.NonNull with commont-only functionality.
2) No checking without JDT\ -- painful. A custom post-builder could check the org.eclipse.jdt.annotation.NonNull annotations.
3) JDT has null analysis\ -- hopefully this won't go. Maybe there will be a JLS standard
4) JDT has null analysis\ -- painful we have to put back all the asserts that we thought were redumndant
5) External annotations have never worked proper;y. After 7 years Bug 414237 is WONTFIX. Clearly the necessary PDE support to migrate the classpath annotations to the MANIFEST so that they are visible to code calling plugins will never happen.
There is no point tolerating inadquate code in the hope of bug fixes that will never happen. We must eliminate the very inadequate dependency on external annotations now. The rest may survive in JDT for a while.