Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove dependency on JSR305 annotations #421

Open
KengoTODA opened this issue Sep 29, 2017 · 14 comments

Comments

Projects
None yet
5 participants
@KengoTODA
Copy link
Member

commented Sep 29, 2017

SpotBugs implementation depends on JSR305 (e.g. TypeQualifierAnnotation.java) so we need to change implementation to remove dependency on outdated JSR305.

refs #180

@rschmitt

This comment has been minimized.

Copy link

commented Jan 18, 2018

Will support for JSR-305 annotations be removed altogether, or will they still be optionally supported?

@kwin

This comment has been minimized.

Copy link

commented Apr 29, 2018

I think this issue is only about removing the dependency from the spotbug annotations module, not from the core in general.

@KengoTODA

This comment has been minimized.

Copy link
Member Author

commented Apr 29, 2018

SpotBugs core also depends on JSR305, so we need to remove it too.

@earcam

This comment has been minimized.

Copy link

commented Jul 13, 2018

Hi,

While I understand that JSR305 != FindBugs/SpotBugs, I don't understand the statement

JSR305 is already Dormant status, so SpotBugs does not release jsr305 jar file. Please continue using findbugs’ one.

(from http://spotbugs.readthedocs.io/en/latest/migration.html)

Given that the JSR305 annotations are used to annotation FindBugs/SpotBugs, doesn't it make more sense to take ownership and port these to a new namespace? Or do I not see the complete picture (is this about the meta/validator side of things or legal?)

It's a little depressing to see com.google.code.findbugs:jsr305:3.0.2 now relegated to a transitive dependency that I cannot... must not use 😉

I'll really miss @javax.annotation.WillClose, @javax.annotation.ParametersAreNonnullByDefault and friends - it would be great to have equivalents somewhere.

Thanks

@KengoTODA

This comment has been minimized.

Copy link
Member Author

commented Jul 13, 2018

Given that the JSR305 annotations are used to annotation FindBugs/SpotBugs, doesn't it make more sense to take ownership and port these to a new namespace?

Please send your PR! I think nobody blocks you to make it real :)

@earcam

This comment has been minimized.

Copy link

commented Jul 13, 2018

@KengoTODA, I've done the preliminary work in a couple of repos:

Built with gradlew build and all tests are passing. The jsr-305 project is refactored as follows:

Old New
javax.annotation com.github.spotbugs.jsr305.annotation
javax.annotation.concurrent com.github.spotbugs.jsr305.annotation.concurrent
javax.annotation.meta com.github.spotbugs.jsr305.annotation.meta

I'm happy to continue working on the jsr-305 to get it into a release-able state (including OSGi manifest and JPMS module-info with JDK1.6 target), but (as indicated by using spotbug's namespace) I'd rather this was owned by SpotBugs long term.

Note: I think it makes sense to still support the FindBugs JSR-305 annotations - the forked branch of SpotBugs largely does that, there are a couple of places in the code that would need updating, these are marked with a //FIXME comment.

Does this sound OK? (if so, PRs on the way)

@earcam earcam referenced this issue Jul 16, 2018

Closed

Rekindle JSR305 under SpotBugs umbrella (WiP) #698

1 of 1 task complete
@ThrawnCA

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2018

The trouble with taking ownership and changing the namespace is that various tools already recognise javax.annotations despite it being dormant. Changing the package name loses those tools.

Is there any way to continue development within the javax.annotations package?

@KengoTODA

This comment has been minimized.

Copy link
Member Author

commented Jul 17, 2018

Note: JSR305 ri (reference implementation) is licensed under BSD-3-Clause.

@KengoTODA

This comment has been minimized.

Copy link
Member Author

commented Jul 17, 2018

Is there any way to continue development within the javax.annotations package?

I know one solution: TypeQualifierNickname. But it means that our implementation still needs to depends on javax.annotation implementation, at least on compile time.

@ThrawnCA

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2018

So...should we be coordinating with @amaembo then? He's a former FindBugs developer IIUC. Are there particular changes that JSR-305 needs, which we might be able to get done?

Switching package names would basically be forking, which should be a last resort.

@KengoTODA

This comment has been minimized.

Copy link
Member Author

commented Jul 17, 2018

should we be coordinating with @amaembo then?

No. Type qualifier nickname is a feature to handle annotation as nickname/facade for another annotation. For instance, Nullable is nickname for Nonnull.

@KengoTODA

This comment has been minimized.

Copy link
Member Author

commented Jul 17, 2018

So I thought that we can annotate our new annotations with TypeQualifierNickname, then tools can treat them as a nickname for JSR305 annotations.

@ThrawnCA

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2018

Nullable is nickname for Nonnull

Um...that's quite contrary to its Javadoc btw. @Nullable is, per the docs, equivalent to having no annotation at all.

we can annotate our new annotations with TypeQualifierNickname, then tools can treat them as a nickname for JSR305 annotations

OK...what is the expected benefit of having the com.github.spotbugs versions? If the annotations need development, then we'll want to backport that to the JSR305 ones, right? And if we make changes that aren't backported, then we lose compatibility again with the tools that will actually use these annotations.

@earcam

This comment has been minimized.

Copy link

commented Jul 17, 2018

The issue is that FindBugs JSR305 causes a split package with module java.xml.ws.annotation which creates a world of pain for Java >= 9

Releasing javax.* without Oracle approval is a license violation AFAIK.

There is possibly another option - ownership of javax.annotation namespace now comes under the EE4J project maintained by Eclipse.

I've submitted a PR for common-annotations-api which would resolve this issue nicely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.