Multiple @Nullable annotations

[a1730]

Thank you for this gem of a cache manager. We are thoroughly enjoying the project.

Is it possible for cache2k to stop exporting its annotations, at least limit exports to the cache2k project, as in exports to org.cache2k.hierarchy?
We find ourselves creating exception rules for the java IDE to not propose those classes as auto-complete candidates.

Thank you!

[cruftex]

Great to hear you are enjoying cache2k.

Unfortunately, the annotation definitions need to be exported, since these are part of the API.
I did a lot of experimentation. At the end I stayed close with the approach of Spring:
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/lang/Nullable.html

An alternative would be to use the annotations from the checker framework. How you think about that?
What nullable annotations are you using in your project?

That is maybe something we could change for the next major (3.0) version.
If others have opinions and wishes about that, please comment.

[a1730]

Thank you for giving consideration to this wacky request.

We currently use ActiveJ extensively and it brought Intellij annotations dependency with it. Then some wise guys started using eclipse-jdt annotations because of @NonNullByDefault. We drew the line on those two ... so we thought. It is a shame that jsr305 died quietly, and its death is causing confusion in Java land. We now have too much of a good thing!

Anyway, given our reliance on ActiveJ framework and Intellij Idea editor, coupled with the reality that there is no good answer, my team would love to settle on Intellij idea annotations if given a choice. We will continue to write code completion exclusion rules until the day. Yes, we already have some rules to eclude checker framework proposals.

Thank you for your considerate response.
Thank you for cacke2k.

[a1730]

One thing we decided was no runtime dependencies for Nullable annotations. This ruled out checker framework. We wanted the runtime safety but we were uncomfortable with the technical debt (one more runtime dependency.) I believe this was what flagged cache2k.

[cruftex]

@a1730, Thank for the background and the additional links!

Yes, we already have some rules to exclude checker framework proposals.

That means that if cache2k would use the checker framework annotations it could have saved you some effort, at least.
So it would improve the situation a bit. I see reasons that we should change in cache2k to an existing library for the @nullable annotations.