Community
Participate
Working Groups
(I don't trust @NullByDefault consequently I always use @NonNull / @Nullable explicitly.) Given: private final @NonNull List<@NonNull TracingStrategy> tracingStrategies = new ArrayList<>(); Source->generate Getter gives public List<TracingStrategy> getTracingStrategies() { return tracingStrategies; } rather than public @NonNull List<@NonNull TracingStrategy> getTracingStrategies() { return tracingStrategies; } But beware, in another scenario a completion gave me a double @NonNull error. It appears that a clean-up null annotations post-processor is required.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
The Getter and Setter should have the annotations added to the return type and to the parameter respectively. Only if the annotation applied on the field is a TYPE_USE annotation should it be applied to the return type and to the parameter of Getter and Setter respectively
ATM, only part of JDT/UI is aware of type annotations: + overriding a method with type annotations reproduces the annotations in the new method's signature. + creating a new local variable from name reference 'tracingStrategies' creates: List<@NonNull TracingStrategy> tracingStrategies2 = tracingStrategies; (the outer annotation is not needed as it is subject to flow analysis). - Generate Getters and Setters doesn't yet participate in this Implementationwise, previous work has been done in StubUtility2.createImplementationStub(). Unfortunately, GetterSetterUtil.getGetterStub() uses a more basic approach to generating the method header. More specifically, this method creates the new method as a plain String, whereas StubUtility2 creates a full-blown AST from actual type bindings (which contain the TYPE_USE annotations). From a quick look I cannot say, how hard it would be to refactor the implementation towards one that is fully based on bindings and AST (see that addNewAccessor() already performs insertion via ASTRewrite, so that looks promising). After such refactoring, making everything annotation-aware might be (close to) trivial. @Kalyan, feel free to ask if you happen to look into this and have questions.
Problem acknowledged; required work identified. Problem of course still exists so not stalebug, but perhaps helpwanted.
