JSR 305 annotations don't play nice with Java 9+ modules

[dbwiddis]

Frustratingly, after spending a few hours looking at what package to include for the @ThreadSafe, @Immutable, and @NotThreadSafe annotations I just added (and released in 4.6.0 earlier today), it seems I made the wrong choice. The Java Platform Module System doesn’t like it when two modules contain types in the same package..

Also, it seems the javax.* packaging runs afoul of the Oracle binary code license section F.

I'm not sure how critical this is since I only used provided scope, but it seems a good idea to find another replacement soon. Open to suggestions for the "best" alternative... including possibly just defining them within OSHI.

[dbwiddis]

Relevant discussion here

[hazendaz]

@dbwiddis I would not use JSR305 right now or any of the numerous duplicate solutions. After 'jakarta' is officially released in June and sometime after when all containers fully support it, the JSR305 is likely to be consumed into jakarta annotations. I'm on the spotbugs team which technically more or less owned JSR305, but the spec lead just went AWOL originally at Oracle per java tech lead and that just never got consumed at that time thus the mess out there. Internally spotbugs has been moved off JSR305 to use it's own annotations which just complicates it even more.

See here

[hazendaz]

by 'jakarta', i'm referring to the entire repackaging effort where 'javax' is going to 'jakarta'. JSR305 isn't allowed to be consumed now due to oracle licensing restrictions on their trademark even though that has existed for many years but wasn't directly in their apis.

[dbwiddis]

Wow, @hazendaz, thanks for the input...

I would not use JSR305 right now or any of the numerous duplicate solutions

I think I've come to the same conclusion after following the numerous threads on the topic. Since I've only gone so far as the 3 quoted above, I can probably just define those within OSHI (to preserve their presence in the javadocs) and hold off on any more expansive use of the null-related, or check-return, or similar until JSR305 is in Jakarta. Or, better, since I'm looking at an API switch, perhaps just start making use of Optional.

oracle licensing restrictions on their trademark even though that has existed for many years but wasn't directly in their apis

Wouldn't the same logic apply to the use of com.sun.* in the JNA project's packaging?

[hazendaz]

I suspect it does. I haven't heard if con.sun is an issue yet. Their main beef was java trademark. But the own sun too. If jna team changed it, I'd be on board. Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: dbwiddis <[email protected]> Sent: Friday, April 3, 2020 3:42:23 PM To: oshi/oshi <[email protected]> Cc: Jeremy Landis <[email protected]>; Mention <[email protected]> Subject: Re: [oshi/oshi] JSR 305 annotations don't play nice with Java 9+ modules (#1160) Wow, @hazendaz<https://github.com/hazendaz>, thanks for the input... I would not use JSR305 right now or any of the numerous duplicate solutions I think I've come to the same conclusion after following the numerous threads on the topic. Since I've only gone so far as the 3 quoted above, I can probably just define those within OSHI (to preserve their presence in the javadocs) and hold off on any more expansive use of the null-related, or check-return, or similar until JSR305 is in Jakarta. Or, better, since I'm looking at an API switch, perhaps just start making use of Optional. oracle licensing restrictions on their trademark even though that has existed for many years but wasn't directly in their apis Wouldn't the same logic apply to the use of com.sun.* in the JNA project's packaging? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1160 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHODI7BWVOU44UQJRCN3ILRKY3Z7ANCNFSM4L3REMEQ>.