The Gradle plugin does not exclude java.* from Import-Package anymore

[jonatan-ivanov]

6.4.x versions of the plugin did exclude java.* from Import-Package while 7.1.x does not.

For Example doing this using 6.4.x:

jar {
    bundle {
        bnd '''\
        Import-Package: \
            javax.annotation.*;resolution:=optional;version="${@}",\
            *
        '''.stripIndent()
    }
}

Results in this:

Import-Package: javax.annotation;resolution:=optional;version="3.0.2",
javax.annotation.meta;resolution:=optional;version="3.0.2"

But on 7.1.x, Import-Package also contains this:

java.io,java.lang,java.lang.annotation,java.lang.invoke,java.lang.management,java.lang.ref,java.lang.reflect,java.math,java.net,java.nio,java.nio.charset,java.sql,java.text,java.time,java.time.format,java.time.temporal,java.util,java.util.concurrent,java.util.concurrent.atomic,java.util.function,java.util.logging,java.util.regex,java.util.stream,java.util.zip,

A workaround could be excluding java.*:

jar {
    bundle {
        bnd '''\
        Import-Package: \
            !java.*,\
            javax.annotation.*;resolution:=optional;version="${@}",\
            *
        '''.stripIndent()
    }
}

[chrisrueger]

Thanks for the report.
It looks as this was done in:

• OSGi Java 9 support: Importing java.* packages #2507
• Add support for importing java.* packages for OSGi Core R7  #4241 (comment)

You can disable it with -noimportjava: true (https://bnd.bndtools.org/instructions/noimportjava.html)

I think this is a breaking change going from 6.x to 7.x.

[kriegfrj]

I think this is a breaking change going from 6.x to 7.x.

Actually, the feature has been "in the wild" since the 5.2.0 release (October 2020).

What seems to catch developers out is that it won't generate java.* imports unless:

• The bundle includes class files for Java 11 or higher, or
• You're using OSGI R7 (org.osgi.framework package v1.9.0) or higher.

What usually happens in these scenarios is that the developer upgrades to a later JDK or later OSGi version on their build path, which triggers this feature when it didn't before.

I was a bit green when this decision was made (even more so than now), but my understanding is that since OSGI R7 it became "best practice" to explicitly import java.. This is because it becomes possible for cut-down versions of the JRE to be used that didn't have all of the java. classes (more common in embedded environments where memory is at a premium). So best practice is to explicitly import the packages that you actually do need, and then the resolver can figure out at bundle load time whether the bundle will resolve on the framework or not.

As Bnd is ubiquitous in generating these manifests, having it implement best practice by default helps to move everyone in the right direction.

[jonatan-ivanov]

Thanks for the replies!
It seems for us the trigger was upgrading the bnd gradle plugin.

I understand the reasoning behind including java.*, would you recommend doing this in our case?

• It's a Java library: https://github.com/micrometer-metrics/micrometer/
• The baseline is Java 8 but we have modules for higher Java versions to support newer Java features (Java 11, Java21 etc.)
• Importing java.* breaks users, I guess because of very old version of libs they use(?): Exclude java.* from OSGI Import-Package micrometer-metrics/micrometer#6810

[chrisrueger]

would you recommend doing this in our case?

I am a bit hesitant to give recommendations. But here is my analysis:

In the linked issue micrometer-metrics/micrometer#6810 (comment) I see the following:

 java -jar .\org.eclipse.osgi-3.10.0.v20140606-1445.jar

this uses a pretty old eclipse equinox framework from 2014 which - I assume - is based on OSGi R6 specification from 2014, and OSGi R7 spec came out in 2018 and OSGi R8 in 2020. (all specs for reference)

OSGi R6 strictly forbidds imports of java. packages*

3.4 Execution Environment
Bundles do not import the java.* packages and can therefore not specify their dependencies on
these variations in the environment using the Import-Package header.

The old 2014 Equinox seems to enforce this rule with the error in screenshot "Invalid manifest header Import-Package: "java.io"

OSGi R7 allows java.*

3.4 Execution Environment
Bundle may also import java.* packages using the Import-Package header. Imports of java.* packages by a bundle will be used during the resolution process, see Resolving Process

That being said:

• Your user (for whom it broke) expects an OSGi R6 compatible jar (which does not allow java.*)
• Since you have built with bnd 7.1.0 you have build for OSGi R8 (which does allow java.*) (5712aad)

Options:

1. Your user could use a new Equinox
2. or if you really want to support older Equinox OSGi R6 versions then you can (or should) remove java.* imports with -noimportjava: true (https://bnd.bndtools.org/instructions/noimportjava.html) to create the behavior you had before.

So far for my analysis.

@laeubi is usually more an expert on this since he has contributed OSGi related things to lots of libraries. Maybe he has some comments or different opinion.

[laeubi]

I think everything is already perfectly outlined here and explained why it happens. I don't think it is really forbidden in the R6 spec it more says you do not need to when using EE but as mentioned here this is really outdated these days and we have Frameworks (namely Equinox + Felix) that support R8, so I don't see a real good reason to not upgrade.

The main reason for this is that the EE becomes more or less useless, it defines the minimal java specification version but there is no guarantee a modular JVM actually contain a fixed set of packages.

So the recommendation would be:

1. Keep java imports, they are actually never bad and contribute to make you bundle more future proof and allows tooling to e.g. generate a stripped down JVM with only the required modules/packages.
2. If you really need to support ancient frameworks use -noimportjava: true to restore old behavior.

[jonatan-ivanov]

Thank you all for the feedback, I really appreciate the help.
We will consider adding java.* imports back in our next minor release.

[kriegfrj]

I want to try and close the loop on this for posterity, in case anyone stumbles across a similar issue in the future:

Thanks for the replies! It seems for us the trigger was upgrading the bnd gradle plugin.

Based on your micrometer-metrics/micrometer#6810 (comment):

I think I found the cause: we upgraded the bnd gradle plugin from 6.4.0 to 7.1.0 in micrometer-metrics/micrometer#5735

... I don't think that this the full story. As I noted, this feature has been around since Bnd 5.2.0 - given that you were already at 6.4.0, upgrading to 7.1.0 should not (of itself) have been the trigger.

There are a couple of other possibilities:

1. I thought I remember reading somewhere (though I can't find it now) that you recently upgraded the version of Felix you were building against. This could have been the trigger if you were upgrading from an OSGI-R6 implementation of Felix to an OSGi-R7 (or higher) implementation.
2. I note that when you upgraded to 7.1.0, you also discovered that you had to upgrade the build environment to JDK 17. This could have been the trigger too, if previously Bnd was being run under a JDK 1.8. If this is the reason, then it means that the upgrade from 6.4.0 to 7.1.0 has indirectly triggered the java.* generation.

[jonatan-ivanov]

you recently upgraded the version of Felix you were building against

We only use felix for tests in a separate testing module, the published modules do not depend on felix. Also, we did not seem to upgrade it between the versions that produce the different behaviors. Where did you see it that we upgraded it in the version that introduces the issue?

I note that when you upgraded to 7.1.0, you also discovered that you had to upgrade the build environment to JDK 17.

We did not upgrade it. We discovered that 7.x will not run with our Java 11 build, only with Java 17/21/23 (24 now) builds so we disabled it only for the Java 11 build and kept using 6.x for the Java 11 job. The published artifacts were always created using Java 21. Where did you see it that we upgraded it in the version that introduces the issue?

If you want to dig deeper:

• You can check the difference between the artifacts of 1.14.8 and 1.14.9, e.g.: micrometer-commons, they are in Maven Central
• Diff: micrometer-metrics/micrometer@v1.14.8...v1.14.9
• gradle/libs.versions.toml -> no felix upgrade but bnd was upgraded
• .circleci/config.yml -> no Java upgrade, it was always Java 21 that created the published artifacts (deploy job -> circle-jdk-executor -> openjdk:21.0.6)

If I revert my "fix" (remove !java.*,\ from every Import-Package) and create the artifacts (using Java 21) with 6.4.0 and 7.1.0 versions of the plugin (not changing anything else) then I get two different values for Import-Package, the one that 6.4.0 creates does not have java.* imports while the one that 7.1.0 creates does have those imports.

Maybe I jumped the gun too soon saying that it seems the trigger was upgrading the bnd gradle plugin (?) but I still don't see anything else that is is suspicious; also, I can reproduce this by only changing the bnd plugin version. If this is unexpected, I guess this issue should be reopened? Please feel free to repro the issue using Micrometer and let me know the outcome or if you have another theory for the root cause (it might be easier to repro it with a minimal project though).

[laeubi]

In in bnd 7.1 the java imports are always activated except if you use an old framework on the classpath:

b3eed2b

• The java imports are now always done except when the used framework
  is < 1.9 (before R7). The EE version is now ignored.

[kriegfrj]

In in bnd 7.1 the java imports are always activated except if you use an old framework on the classpath:

That explains it, well spotted!

[chrisrueger]

I added a hint about this to the 7.0.0 Release notes https://github.com/bndtools/bnd/wiki/Changes-in-7.0.0
Note that b3eed2b was part of 7.0.0 already.