addressalign-toparrow-leftarrow-leftarrow-right-10x10arrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcredit-cardcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobe--smallglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1languagelaunch-new-window--smalllight-bulblightning-boltlinklocation-pinlockm-swarmSearchmailmediummessagesminusmobilemoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstar-shapestartickettrashtriangle-downtriangle-uptwitteruserwarningyahooyoutube

Re: LJC - London Java Community list: "Save a dormant JSR? (jsr-305 in a post JPMS world)"

From: Martijn V.
Sent on: Friday, July 20, 2018, 12:23 PM
Hi Caspar,

We have a seat on the JCP EC and I'm happy to bring this up as an agenda item in our next call.  There is a process where JSRs can be handed over to the spec lead (with the accompanying IP flow) but that requires the permission of the original spec lead and potentially (depending on legalities) Oracle as well.

Have you heard anything back from the Spec Leads yet?


Cheers,
Martijn


On Thu, 19 Jul 2018 at 23:33, Caspar MacRae (Meetup) <[address removed]> wrote:
Meetup
Caspar MacRae
Caspar MacRae (Member) sent a message to the LJC - London Java Community mailing list
Save a dormant JSR? (jsr-305 in a post JPMS world)

Hello,

A somewhat reduced and trivialised history: 
JSR-305 proposed a bunch of annotations for static code analysers etc, but for reasons historical and irrelevant to this discussion it was never ratified.  Relevant to this discussion, but for reasons unknown, the com.google.code.findbugs:jsr305 jar was released and widely consumed *.

The problem:
JSR-305 made use of the javax.annotation package root, as does JSR-250.  This causes a split-package, which is resolvable in OSGi but a private repo hackfest for JPMS.

So it looks like the solution for dependent projects will be; first look for the FIndBugs/SpotBugs equivalents, then find no one-to-one global search-n-replace and likely opt to just remove this valuable metadata **.

A possible solution:
Eclipse (via EE4J) are stewards/custodians of the migrated JSR-250 (rebranded as common-annotations-api) and therefore rightful heir to the javax.annotation package.  As such, and ignoring legal issues, this is the only possible home for findbugs-jsr305.

Questions:
I can't see that such a licensing reprieve would be to any party's detriment - but certainly recognise this is legal headache.

In response to raising a PR with EE4J, project member @ggam helpfully indicated that the IP was a potentially owned by either spec leads or the JCP and that Oracle would ultimately have to consent to the namespace usage.

Is there any possibility of requesting Oracle/JCP to release the IP of a dormant JSR to EE4J? 

Thanks (and apologies for length),
Caspar


* evidence for "widely used"; mavenrepository.com stats list 5k direct dependencies - this list includes SLF4J, Guava, Spring, Hadoop, Spark, Jersey, Maven Plexus...

** justification for "valuable metadata"; largely the previous "widely used" "evidence"

Please note: I have already emailed the original JSR leads and requested they opine - so unless you are a personal acquaintance of theirs, respectfully, please don't spam/hound them with similar.

Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

You received this notification because you're a member of LJC - London Java Community, organized by Barry Cranford.

Never miss a last-minute change. Get the app.

iPhone App Store Google Play

You're getting this message because your Meetup account is connected to this email address.

Unsubscribe from similar emails from this Meetup group. Manage your settings for all types of email updates.

Meetup will always send you information about: your account, security, privacy & policies, and payments. Read our Privacy Policy

Report this message.

Block message sender.

Visit your account page to change your contact details, privacy settings, and other settings.

Meetup, Inc., POB 4668 #37895 New York NY USA 10163. Meetup is a wholly owned subsidiary of WeWork Companies Inc.

People in this
group are also in: