OSGi import of javax.annotation and javax.annotation.meta is broken in 1.14.2

[steinarb]

In jsoup version 1.14.2, the OSGi import of the package javax.annotation is imported with a version >= 3.0 and < 4.0.

This makes the jsoup 1.14.2 bundle fail to load on apache karaf which provides version 1.3.0 of the package (from the apache felix runtime).

Possible fixes:

1. Check if the import is actually sed at runtime, and remove the import of javax.annotation, if it isn't actually needed (earlier versions of jsoup does not have this import)
2. Remove the versioning of the import (the actual content of the javax.annotation package has AFAIK not changed since, like, forever)
3. Expand the version range on the javax.annotation import, from [3.0, 4) to [1.0, 4)

Not sure where the 3.0 version of the import comes from...?
I have googled, and think, maybe from this 2011 vintage, org.glassfish rebundling of javax.annotation? https://mvnrepository.com/artifact/org.glassfish/javax.annotation

The javax.annotation.meta package will probably also have to be handled in the same way?
From the MANIFEST.MF of jsoup 1.14.2:

Import-Package: javax.annotation;version="[3.0,4)",javax.annotation.meta
 ;version="[3.0,4)",javax.net.ssl,javax.xml.parsers,javax.xml.transform,
 javax.xml.transform.dom,javax.xml.transform.stream,org.jsoup;version="[
 1.14,2)",org.jsoup.helper;version="[1.14,2)",org.jsoup.internal;version
 ="[1.14,2)",org.jsoup.nodes;version="[1.14,2)",org.jsoup.parser;version
 ="[1.14,2)",org.jsoup.safety;version="[1.14,2)",org.jsoup.select;versio
 n="[1.14,2)",org.w3c.dom

[steinarb]

The "culprit" is the provided dependency to mvn:com.google.code.findbugs/jsr305/3.0.5.

I.e. this is where version 3.x in the import in the MANIFEST.MF comes from.

[steinarb]

I've created the PR #1617 that fixes the issue by removing the version requirements from the javax.annotation.* package imports.

[jhy]

(See also notes in #1618, reported coincidentally to this report)

Thanks for the analysis and the PR, very helpful!

[jhy]

@pgorny @steinarb could you please test on head (i.e. install the snapshot version) and confirm that the fix works -- that you can load the bundle without errors?

[pgorny]

@jhy It does not resolve it for me. It fixes the version dependency (so javax.annotation can be provided by any software), but not the fact that a import of javax.annotation.meta is still a required dependency.

A solution would be to make the resolution of those optional, something I've created a PR for in #1619.

[steinarb]

@jhy It does not resolve it for me. It fixes the version dependency (so javax.annotation can be provided by any software), but not the fact that a import of javax.annotation.meta is still a required dependency.

A solution would be to make the resolution of those optional, something I've created a PR for in #1619.

I mentioned the javax.annotation.meta problem in a comment on my PR, but it probably got lost.

What's fetched from javax.annotation and javax.annotation.meta are annotations with runtime retention.
Not sure what happens if they aren't available at runtime...?
The single problematic one, is the one from javax.annotation.meta, can that be replaced with something else?

[pgorny]

What's fetched from javax.annotation and javax.annotation.meta are annotations with runtime retention.
Not sure what happens if they aren't available at runtime...?
The single problematic one, is the one from javax.annotation.meta, can that be replaced with something else?

@steinarb If they are not available at runtime this OSGI bundle will fail to start due to missing requirements and any dependents will do the same. javax.annotation.meta is particularly problematic in that nothing else apart from the findbugs/jsr305 loaded at runtime seems to provide it - so basically the choice is either to ensure the annotation is used as build-time only or to install JSR305 bundle into the OSGI runtime as well.

[steinarb]

FWIW what I've done for now is to add findbugs/jsr305 to the OSGi runtime.

And it does seem to work, so far. But I'm unsure about the effect on other applications of pulling in another javax.annotation into the runtime?

The two javax.annotation packages have different versions so they aren't in conflict and can co-exist inside OSGi, and packages with versioned dependency will pick the right one.

The problem is that I suspect that most imports of javax.annotation are without version, and I suspect they would pick the one with the highest version number (assuming it to be the newest) and I heard rumors that findbugs/jsr305 javax.annotation differs from the regular javax.annotation, and my worry is that pulling in findbugs/jsr305 can break other stuff (in my case: Jersey JAX-RS resources using HK2 dependency injection).

[jhy]

OK thanks for this. I have gone for #1619 as it seems most appropriate. The annotations are intended to be used at development time only (which is not exactly build-time). But including them as resolution:optional should leave the way to run-time annotation inspection if that's needed for someone's use-case.

If we see issues down the line we can of course revisit.

I will now gripe about the difficulty of finding a useful way to include non-null assertions that are not license encumbered. Further, I added them with the intent of improving how Kotlin integrates with the library, but it turns out that it basically ignores them all, as it gave up on null/non-null strictness on Java method returns a few years back, and just treats everything as hand-wavey safe / maybe unsafe.

[jhy]

(@pgorny @steinarb, can you please re-test? Thanks!)

[steinarb]

@jhy I can confirm that jsoup 1.14.3-SNAPSHOT built from the current master (and with resolution optional in the MANIFEST.MF (I checked)) works fine for me, in my apache karaf applications, without requiring findbugs/jsr305 to be loaded.

[pgorny]

@jhy And I can confirm in my Felix application - javax.annotation is resolved from Geronimo annotations, javax.annotation.meta is ignored.

[jhy]

Fantastic, thanks!

[lohitghongadi]

@jhy Could you please let me know when will this be available to consume? Currently, I don't see a due date for the 1.14.3 milestone.
https://github.com/jhy/jsoup/milestone/21

[jhy]

Probably in a month or so. I have some other things I plan to add.

If you are blocked in the meantime, I would suggest doing a maven install and using the snapshot.

[steinarb]

Not blocked as such. But the other github message today was a nag about fixing a particular security issue in some of my projects...;-)

[jhy]

Got it; will shoot for earlier rather than later

[darklynx]

I'm joining those who waits for release 🙄
Thank you in advance!

[rhierlmeier]

I am also waiting for the release. Vaadin 8.14.0 has a dependency to jsoup 1.14.2. It can no longer be deployed in an OSGI environment, when any other bundle imports also javax.annotation.

See https://mail-archives.apache.org/mod_mbox/karaf-user/202109.mbox/%3CCAJHKGXub9tqoVx7h%3DmiPK0zaOGy7Q%2BBZaJFXtVGLiP-dZ3COzQ%40mail.gmail.com%3E

[andalesV]

I am also waiting for the release.
Thank you

[jhy]

Good news everyone! Jsoup 1.14.3 is available now: https://github.com/jhy/jsoup/releases/tag/jsoup-1.14.3

(BTW going forward, best to just give a thumbs-up to the issue or a note vs adding a "me too" comment that you're waiting on a release, unless you have extra detail. That helps reduce clutter, and you'll still get notified from watching the issue)

[grgrzybek]

mvn:com.google.code.findbugs/jsr305/3.0.5 is one of the most problematic OSGi artifact in Maven Central. I hit this problem many times.
There are officially 3 versions of Java Annotation specifications:

• 1.3 - standard JavaEE version with the official API JAR at javax.annotation or jakarta.annotation groups in Maven Central
• 2.0 - JakartaEE 9
• 2.1 - JakartaEE 10

JSR305 (the artifactId) comes from actual JSR 305 from JCP, but there's no official information that com.google.code.findbugs/jsr305 is an official RI of this specification.

The well known JSR 250 should be THE specification that defines javax.annotation package. This is one of the mysteries why the same (split) package was used for JSR 305. Maybe Google was too fast? They didn't check JSR 250? Didn't expect the problems?

There are no common classes between javax.annotation packages in javax (or jakarta) annotation-api and Google jsr305. In my opinion, optional:=true is the right thing to do (ensuring that the version range stays at [3,4)). I checked that jsr305's annotations have:

@Retention(RetentionPolicy.RUNTIME)

So these annotations should not be treated as dev/build only...

Anyway - we'll have to live with this situation till the heat death of the Universe.