Can the osgi.ee=JavaSE be more lenient on unknown JDK versions?

[ben-manes]

As an OSGi novice, I was very confused when my tests failed on JDK-25 and the Pax Exam team kindly helped me resolve that setting the Require-Capability explicitly. Since this is just the Java version can that be added dynamically instead of osgi.ee;filter:="(osgi.ee=UNKNOWN)"? Then the bnd plugin is future compatible. While I release on JDK-11, the tests failed due to cross-building on the latest JDK.

# Java 24
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=24))"

# Java 25
Require-Capability: osgi.ee;filter:="(osgi.ee=UNKNOWN)"

I manually forced the correct value using,

// Workaround until the bnd plugin supports the latest JDK
val javaVersion = java.toolchain.languageVersion.get()
if (javaVersion.canCompileOrRun(25)) {
  bnd(mapOf("Require-Capability" to
    """osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=${javaVersion}))""""))
}

[chrisrueger]

I think this will be fixed in upcoming bnd 7.2.0 which added support for JDK24 and JDK25.

• https://github.com/bndtools/bnd/pull/6529/files#diff-85fbc89f0c6509380298a0e20b8a5520338a927f87b7f85ff882a678c6cbf35e
• add JDK25 support #6672

[ben-manes]

Great, but won’t it reoccur in 26, etc? Is there a reason to require a parallel release? That change adds up to 30 which is nice, but seems like it should be dynamic?

[chrisrueger]

Well good question. I remember the consensus was to increase the JAVA constants up to 30. I just tried to follow the existing pattern.

@bjhargrave @pkriens any comments?

[chrisrueger]

I created an experimental PR to adress this #6859

But I am not sure yet, if this "dynamic" is a good idea.
Because this is looking into the crystal ball a bit. bnd parse java class files to determine the major_version which is used to calculate the number XX after JavaSE-XX. What we don't know is how long will bnd's Java .class parser be working in a yet unknown future. It might work for just extracting the major_version, but could fail for other parts.

But let's wait for some more feedback from others.

[chrisrueger]

@kriegfrj I remember you once mentioned something related to the Require-Capability: osgi.ee;
Do you have any opinion on the above and the PR #6859?

[kriegfrj]

Great, but won’t it reoccur in 26, etc? Is there a reason to require a parallel release? That change adds up to 30 which is nice, but seems like it should be dynamic?

Separate to @chrisrueger 's proposed fix, I believe you can explicitly specify the require capability and hard-code the version you want. This could work as a workaround.

[chrisrueger]

Thanks @kriegfrj. Do you see any problem with my proposed PR? For me it was more an experiment, and I am a bit unsure. After my initial doubt above I think it is ok, since we are iterating over all classes anyway to extract the major_version. My fix is just an improvement and alternative to the UNKNOWN enum value.
I just wonder if this is ok to do, or if I should just add some more enum e.g. up to Java/40 to last a bit longer in the future.

[chrisrueger]

I believe you can explicitly specify the require capability and hard-code the version you want. This could work as a workaround.

@ben-manes adding to @kriegfrj comment there is a bnd instruction -noee: true https://bnd.bndtools.org/instructions/noee.html which might be good to know (for others coming here) in this context. -noee: true basically disables the adding of the Require-Capability: osgi.ee at all and leave it totally up to you.

Regarding my PR: As I have not yet heard more feedback from some of the old bnd guys (some are on the road), I have not merged yet, since it is pretty core (and given the fact that it will be fixed for a while in 7.2.0 and workarounds exist). So I guess it might take a little while.