Bug 489427 - [null] Illegal redefinition of parameter P, inherited method from Parent does not constrain this parameter makes for poor usability of null analysis with 3rd party libraries
Summary: [null] Illegal redefinition of parameter P, inherited method from Parent does...
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.5.1   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: needinfo
Depends on:
Blocks:
 
Reported: 2016-03-11 07:33 EST by yac yac CLA
Modified: 2022-07-21 02:18 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description yac yac CLA 2016-03-11 07:33:13 EST
Illegal redefinition of parameter P, inherited method from Parent does not constrain this parameter makes for poor usability of null analysis with 3rd party libraries.

Situation is such that we have a

interface 3rdPartyLib {
  public void method(Param P)
}

where the lib is un-annotated, but it should be annotated with @NonNull.

and our implementation with package wide @javax.annotation.ParametersAreNonnullByDefault

which causes the above error.

The obvious solution would be to annotate the third party lib but that's practically unreasonable, as it is unreasonable to stop whatever we do and start annotating dependencies. Furthermore it is impractical as library provider may not want to include null annotations or take much time to merge the changes and also this creates repackaging burden.

Another "solution" would be to make what some people refer to as "quick fix" to make compiler happy is to just annotate the subtype with `@Nullable Param P`, but that is not really true. `null` is not really accepted there.

So far, for new code I have settled on moving the subtype into extra package that does not have ParametersAreNonnullByDefault but find that suboptimal as it creates needless package fragmentation, which would be especially an issue when annotating existing code.

We need a way to demote this error into a warning and then have a way to suppress it for cases where we know, the parent really takes @NonNull, just do not annotate it.
Comment 1 Stephan Herrmann CLA 2016-03-11 10:09:09 EST
(In reply to yac yac from comment #0)
> The obvious solution would be to annotate the third party lib

Before entering discussion let me ask: are you aware of JDT's support for "external annotations"? See http://help.eclipse.org/topic/org.eclipse.jdt.doc.user/tasks/task-using_external_null_annotations.htm
Comment 2 yac yac CLA 2016-03-11 10:31:37 EST
I started investigating it more just after I filed this bug when I noticed it has an asistent to create the external annotations from within eclipse but so far the external annotation did not take effect for me. I have no idea why, attempted upgrade to 4.6.m5 and now it's even worse. I'll get back to this when I have more information.
Comment 3 yac yac CLA 2016-03-11 12:14:14 EST
So far I have followed with new bug 489445.
Comment 4 Eclipse Genie CLA 2020-07-06 16:20:57 EDT
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.
Comment 5 Eclipse Genie CLA 2022-07-21 02:18:30 EDT
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.