Javac problems with classes using @ServiceProvider annotation

DEVELOPMENT
1

Just FYI, I tried to help FasterXML add some missing @ServiceProvider annotations to Jackson, but it did not end well.

Not sure what else can be done here :thinking:.

Cheers,
Chris

2

Similar misery now being reported here. Any idea how to fix this please? (Other that hand-writing the OSGi metadata, which I consider to be fragile and error-prone.)

Thanks,
Chris

3

I would just do the manifest headers ā€¦ Its easy, will never cause these kind of problems. The annotations are nice for OSGi builds but they quickly annoy other people because they ā€˜donā€™t get themā€™.

Manifest headers are a bit more work on your side but they have much wider acceptance.

4

The advantage of using annotations is that the metadata will probably remain correct after someone else (who most likely wonā€™t have a clue about OSGi) decides to refactor those packages.

I think the compiler issue revolves around the use of an Enum in the annotation, which I added to make the requirement ā€œoptionalā€.

5

We can replace the use of enums. I did this same thing for the OSGi annotations and it is was fully source compatible and Bnd doesnā€™t care if they are enums or Strings.

6

Thanks, although if Bnd 7.0.0 will require Java 17 then Iā€™d likely need a 6.4.1 release in order to use it. (Although this sounds like a binary-incompatible changeā€¦ :person_facepalming:)

7

No, because the annotations are CLASS retention (and processed by Bnd tooling), there is no runtime aspect for which there could be binary incompatibility.

Your build system cannot use Java 17?

8

Iā€™m actually helping out the FasterXML guys here, but FWIW we are still targeting Java 11 too.

9

It is not about what version you target, but what JDK you build with. OSGi still targets Java 8 (--release 8) but builds with JDK 17.

10

Weā€™re using Gradle toolchains, so the compiler will run on Java 11 even if Gradle itself may be running on Java 17.

11

Great, so then Bnd Gradle plugins will be running in the Gradle Java 17 VM.

12

Although that wonā€™t be enough:

    implementation("biz.aQute.bnd:biz.aQute.bndlib:$bndVersion") {
        transitive = false
    }
13

I am not sure what the problem is there. If running in a OSGi environment, then pom dependencies are meaningless.

14

Weā€™re using some code from bndlib at various places, and Iā€™m assuming it will also become Java 17. Which means it wonā€™t run on a Java 11 JVM, of course.