I prefer option 2, Revert to OSGi R6 baseline. It's more compatible and causes less developer pain.
On Fri, Oct 24, 2025 at 8:02 AM Piotr P. Karwasz <[email protected]> wrote: > > 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] > -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
