common-annotations-api

common-annotations-api copied to clipboard

Although JSR305 was never approved, lots of projects and tools use the ones from com.google.code.findbugs:jsr305 (which also include those from net.jcip:jcip-annotations).

Given that common-annotations-api is the new collective home for javax.annotation, adding these annotations would resolve the split-package issue and allow many projects to continue to build with a simple dependency switch.

Related: https://github.com/spotbugs/spotbugs/issues/421 https://github.com/spotbugs/spotbugs/pull/698

I have previously signed the ECA ([email protected])

Note that the intellectual property of these files is owned by the JCP and the specification lead, which could be an individual at that time (https://jcp.org/en/jsr/detail?id=305) so perhaps not even Oracle could contribute the code. In addition, you'd need Oracle to approve the use of those javax.* classes.

As a sidenote, if I'm not mistaken, Oracle never approved the published artifacts that make use of those classes and so they are really illegal.

@ggam knew the copy+paste+PR was always going to be the easier bit...

I was hoping for reprieve on grounds of harmless historical illegality.

Wasn't aware of the exact IP details, thank you for the information. I have emailed the London Java Community (which has a seat on JCP and a fair number of experts), to see if anyone will opine on legal challenges.

Side note: To support claims of used by "many projects", am trying to find a way to query maven central for total (direct and transitive) dependents. So far all I can find is mvnrepository stats which lists 5,052 direct dependencies (this list includes SLF4J, Guava, Spring, Hadoop, Spark, Jersey, Maven Plexus).

@earcam did you receive any answer about this?

@ggam yes I messaged the spec leads (one was busy, one responded positively) and then my local JUG (Martijn Verburg responded positively and kindly agreed to champion this, including the JCP/Oracle/legal bits).
May I add to your z06... email to a thread with Martijn (which includes exchange with spec lead)?

Thanks for the info. And yes feel free to include me on the conversation!

El sáb., 8 sept. 2018 11:50, Caspar MacRae [email protected] escribió:

@ggam https://github.com/ggam yes I messaged the spec leads (one was busy, one responded positively) and then my local JUG (Martijn Verburg responded positively and kindly agreed to champion this, including the JCP/Oracle/legal bits). May I add to your z06... email to a thread with Martijn (which includes exchange with spec lead)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eclipse-ee4j/common-annotations-api/pull/5#issuecomment-419628022, or mute the thread https://github.com/notifications/unsubscribe-auth/ACAucLwz5Jz6HF-_jXOdTtFvV9QGA2Blks5uY5LbgaJpZM4VSjXW .

Any progress?

@earcam @dblevins I think we could make a collaborative efforts like the one here with Apache NetBeans project https://github.com/apache/netbeans/pull/1764

+1

The "javax.annotation" problem really is a mess because of the mentioned split package problem. There is also a dicsussion going on at the Guava project (See issue Migrate off of jsr305). I guess any solution would be highly welcome.

In addition, you'd need Oracle to approve the use of those javax.* classes.

I think it would be fine to directly migrate to the jakarta.annotation namespace instead of using javax.annotation. Changing the annotations to the jakarta prefix is less effort compared with circumventing the split stuff.

How about changing the namespace to "jakarta" and the merging this PR?

As I cannot change the original PR, I created a new one: https://github.com/eclipse-ee4j/common-annotations-api/pull/91

AFAIK, putting stuff into javax namespace is prohibited

AFAIK, putting stuff into javax namespace is prohibited

As I understand, the whole idea is that PR in this specific project because "jakartaee" still have permissions to use "javax" namespace. However that may be not true or only partially true. So it's necessary to clarify if that permitted or not and what exactly blocks this PR.