eclipse-ocl-bot
commented
1 month ago By Ed Willink on Jun 13, 2015 16:35
Bug 470034 has a couple of ideas as to how to have clean but annotated source code.
Open eclipse-ocl-bot opened 1 month ago
eclipse-ocl-bot
commented
1 month ago By Ed Willink on Jun 13, 2015 16:35
Bug 470034 has a couple of ideas as to how to have clean but annotated source code.
| --- | --- | | Bugzilla Link | 470122 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 13, 2015 04:35 EDT | | Modified | Jun 13, 2015 16:35 EDT | | See also | 470034 | | Reporter | Ed Willink |
Description
Today, just before Mars, we have no Java 8 users with Java 8 @NonNull.
In a fortnight, the Java 7 / Java 8 @NonNull conflict that has been a major pain for our development becomes a legitimate conflict for our source level users.
In principle our export of build.properties ensures that our Java 7 @NonNull is used, so it all just works. Only known anomally is that F3 can go to the wrong @NonNull.
If everything works perfectly, a Java 8 user could use Java 8 @NonNull in their own code and benefit from Java 7 @NonNull annotations when invoking our APIs. "perfectly" is a bit hopeful. Realistically there may be some confusing warnings or worse.
If we move to Java 8, a Java 7 user may then see different excitements.
Including Java version-specific proprietary @NonNull annotations in the SDK seems to be imposing our Java practices on users.
Suggest:
The default SDK which contributes the sources to Import->Plugins and Fragments is @NonNull free.
An optional Annotated-SDK has the @NonNull annotations direct from GIT.
So we have to have an automated @NonNull stripper to create the traditional SDK.