Hi Subrhamanya, On 23.10.2025 08:56, Subrhamanya Hebbar wrote: > Now I want to understand is there any possibility to conclude what the base > OSGI version needs to be? I am not sure if this was discussed and then > updated or was due to uplifting bundle plugin. Either way, I didn't see > anywhere it's announced or discussed. This would be one of the biggest > breaking changes from apache commons team to the OSGI applications though.
Thanks for raising this topic: it definitely needs a clear project-wide decision. As far as I can tell, Apache Commons has never explicitly defined an OSGi baseline, and recent behavior changes were not based on any prior discussion. The recent switch from OSGi R6 to R7 behavior was an unintentional side effect of upgrading the BND tooling, not a deliberate policy choice. Since Commons does not directly depend on OSGi APIs, the baseline cannot be inferred from our dependencies. (Disclaimer: I am not an OSGi user myself, so corrections from OSGi experts are welcome.) ## Why did java.* imports suddenly appear? Recent versions of Bnd started generating `Import-Package` entries for `java.*` packages, whenever the library is compiler using JDK 11+ (see `-noimportjava` option [1]). Importing `java.*` is only valid in OSGi R7 and later (see Section 3.4 of the OSGi Core R7 spec [2]). That means our bundles unintentionally stopped resolving on older OSGi frameworks. ## Proposal: define a clear baseline I think we have two realistic options: Option 1: Keep OSGi R7 baseline (current state) - On OSGi < R7: bundles may fail to resolve unless system packages are manually configured as explained by Zac in [3]. - On OSGi R7+: bundles get validation of missing Java modules (fail fast if required JPMS modules are not present). Option 2: Revert to OSGi R6 baseline - Most portable option: works on R6 and later without extra configuration. - Slightly less strict runtime validation for modular Java environments. ## Suggested policy Since custom JREs are rare, the improved validation in OSGi R7 might not be significant in practice. A couple of years ago, we have a short exchange about OSGi baseline in Log4j [4] and we decided to keep OSGi R6 as baseline for the 2.x line (which has a Java 8 baseline) and use OSGi R7 for the 3.x line (which had a Java 11 baseline). Therefore we could align Java and OSGi baselines this way: Java baseline -> OSGi baseline ------------------------------------ Java 8 -> OSGi R6 Java 11 -> OSGi R7 Java 17 -> OSGi R8 Therefore I would propose to revert Commons libraries to OSGi R6 for now and officially document the baseline. What do you think? > Atleast for us, we need some time to move to OSGI 7 since we are on OSGI > 4.3 and trying to move to Java 11. These OSGI products are deployed in > client side and hence we need some time. Thanks for the context. Could you share a bit more about your upgrade strategy? Based on your Micrometer issue [5], it looks like your runtime already mixes Equinox bundles from multiple eras (2009–2014). Would upgrading just the system bundle (`org.eclipse.osgi`) be a possible path for you? Equinox maintains strong backward compatibility, and recent versions (e.g. 3.23.200) still support Java 8 while adding newer OSGi features. That could let you use current Commons libraries without a major platform migration or breaking your existing bundles. One practical note: even if the PMC agrees on setting OSGi R6 as the baseline, we still need to align with the Commons release schedule. With more than 40 active components, releases are queued months ahead, and Gary already has a backlog of planned releases. So I honestly don't know when the next `commons-lang3` release will be, even if we agree on the baseline quickly. ## About CVE-2025-48924 If your upgrade is driven by CVE-2025-48924 [6]: 1. It may not be exploitable in most real applications. For example, Apache Solr is unaffected [7]. 2. If you still want to upgrade, a simpler path could be: - Update `org.eclipse.osgi` to 3.23.200 (latest) - Use `commons-lang3` version 3.19.0 (latest) Piotr References: [1] https://bnd.bndtools.org/instructions/noimportjava.html [2] https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-execution.environment [3] https://lists.apache.org/thread/0l2nhxfkym9qr1ptm07n221z65mj6zop [4] https://lists.apache.org/thread/w3so59ltcgbxd8s3gwfn107o9nchd6cb [5] https://github.com/micrometer-metrics/micrometer/issues/6810 [6] https://www.cve.org/CVERecord?id=CVE-2025-48924 [7] https://github.com/apache/solr-site/pull/152 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
