Cannot get JSpecify annotations to work like org.eclipse.jdt.annotation specifically with generics #3434
Comments
|
It also could be because the JSpecify annotations have a true See #2538 also For me to investigate... EDIT My assumptions were correct. It is the above code that does the magic based on annotation value. A workaround is to make your own Eclipse JDT annotation with the same @Documented
@Retention(RetentionPolicy.CLASS)
public @interface FakeNonNullByDefault {
DefaultLocation[] value() default { DefaultLocation.PARAMETER, DefaultLocation.RETURN_TYPE, DefaultLocation.FIELD, DefaultLocation.TYPE_BOUND, DefaultLocation.TYPE_ARGUMENT };
public enum DefaultLocation {
PARAMETER,
RETURN_TYPE,
FIELD,
TYPE_PARAMETER,
TYPE_BOUND,
TYPE_ARGUMENT,
ARRAY_CONTENTS
}
}Or just use JDT Eclipse annotations only on the package-info.java (and the jspecify ones). |
|
I added the fake Eclipse JDT annotation hack for this repo and it worked: And it already found a bug (in my code): https://github.com/jstachio/ezkv/blob/f6f2f373e3e1a4bf23147b5aaea86e195bd2a800/ezkv-kvs/src/main/java/io/jstach/ezkv/kvs/DefaultKeyValuesResourceParser.java#L279 ( I have Checkerframework, Errorprone, and Nullaway (currently off) for that project and none of them found that issue. That is why I think the Eclipse null analysis is so valuable! I guess maybe we have something hardcoded for JSpecify or should have some option of where we can add default locations by annotation name? |
Thanks for sharing this feedback! |
|
@agentgt concerning Two problems actually: Firstly at Secondly, if we were able to resolve the annotation type, what default locations should we assume to be affected? Without doing the full #390 right now, I think it's fair to start with just these two tweaks:
If you want to try addressing these two issues, I'd be happy to advise where necessary and review a PR. |
|
@stephan-herrmann Sorry for the late reply. I will start looking into this. It might be after Christmas that I have a PR. In the meantime I will look into making sure I have signed off with Eclipse foundation. I think I have already done the ECA but it was a long time ago. I'm fairly sure JDT requires that for contributions correct? |
take your time and don't let it spoil your Christmas time off.
Right, ECA is required (and automatically checked for each PR). thanks |
|
This is more for me at the moment as I'm going to be in the same method but I got this exception while copying some eclipse settings to another project: |
@stephan-herrmann
I cannot replace Eclipses null annotations with JSpecify because generics appear to be not marked.
Here is the project.
https://github.com/agentgt/jdt-null-issue
The project does not work with headless at the moment because there appears to be another bug with plexus eclipse compiler not finding jspecify however it does emit the same warnings as the UI so I will paste its output here:
EDIT here are the errors in the UI
While I have checked in all the eclipse settings I'm going to show the relevant ones below:
My guess is to why this is happening is that annotations besides the eclipse ones are assumed not to target generics.
That is all other annotations are treated like:
To import my reproducible project you may need to adjust the
.classpathto add the EEA. I have not added every EEA of the JDK but just the ones I know it needs.I'm going to tag @sebthom as they are also one of the few that know Eclipse null analysis.
If I replace all the annotations with the Eclipse ones (and make the Eclipse ones primary) the issues go away.
@stephan-herrmann I'm happy to help anyway including code diving. I know promised help before but I have finally finished a bulk of opensource work and eager on making Eclipse null analysis one of the best jspecify-like options.
The text was updated successfully, but these errors were encountered: