paulrutter opened a new pull request, #552: URL: https://github.com/apache/felix-dev/pull/552
> [!WARNING] > **Draft / prototype — not for merge.** There is an unresolved licensing question below that blocks this as it stands. Prototype exploring @tjwatson's suggestion in https://github.com/apache/felix-dev/pull/433#issuecomment-3073468820 that Felix and Equinox should share a cooperative mechanism for the `java.net.URL` factory singletons. Branches off, and targets, #433. ## The problem `URLHandlers` claims the JVM-wide `URLStreamHandlerFactory` by reflectively swapping a private static field on `java.net.URL`, via `SecureAction.swapStaticFieldIfNotClass`. Obtaining a `MethodHandles.Lookup` trusted enough to do that is the **only remaining reason the framework uses `sun.misc.Unsafe`** — the `staticFieldOffset`/`getObject` steal of `IMPL_LOOKUP`. It also means whichever framework installs itself last wins the singleton, so Felix and Equinox cannot coexist in one JVM without clobbering each other. To be clear about urgency: this is **not** a JDK 25 blocker. That `Unsafe` block is guarded by `catch (Throwable)` and falls back to `AccessibleObject.setAccessible`, so on JDK 25 it only produces the familiar warning. This is about JDK 26+ and about framework interop. ## What this does - Vendors the 11 plurl sources from [eclipse-osgi-technology/plurl](https://github.com/eclipse-osgi-technology/plurl) (commit `6581777`) into `org.apache.felix.framework.plurl`. The **only** change is the package rename; every license header and copyright notice is preserved verbatim. This mirrors what Equinox did in https://github.com/eclipse-equinox/equinox/pull/848. - Adds `PlurlURLHandlers`, adapting `URLHandlers` to `PlurlStreamHandlerFactory` / `PlurlContentHandlerFactory`. Plurl installs one cooperative router through the supported `URL.setURLStreamHandlerFactory` API and routes by asking each registered factory `shouldHandle(Class)` — which maps directly onto what `URLHandlers.getFrameworkFromContext()` already does by hand, and needs no `Unsafe`. Verified on JDK 25: the framework compiles and its test results are unchanged. ## ⚠️ Licensing — @tjwatson could you confirm? Every vendored source file declares: ``` SPDX-License-Identifier: EPL-2.0 Copyright (c) 2025 IBM Corporation ``` but plurl's own `LICENSE` file and its `pom.xml` both declare **Apache-2.0**. (Its `NOTICE` also still refers to "slf4j-osgi", which looks like a copy-paste leftover.) This matters because of where it is being copied *to*. EPL-2.0 is [Category B](https://www.apache.org/legal/resolved.html#category-b) at the ASF and must not be included in an Apache **source** release. Equinox was free to vendor these files because Eclipse projects are EPL-2.0 natively; Felix is not. Given the repo's LICENSE and pom say Apache-2.0, my guess is the EPL headers are carried over from the original Equinox code rather than intended. **Could you confirm the intended license and, if it is Apache-2.0, correct the source headers upstream?** That would unblock the vendoring approach for Felix and anyone else. If the headers are intentionally EPL-2.0, then Felix cannot vendor the sources and the options become: 1. consume plurl as a released binary dependency under the Category B rules — which additionally needs plurl published to Maven Central, as it currently has **no release or tag**; or 2. write an Apache-2.0 implementation of the same design in Felix, which works but forks the effort rather than converging on the shared library. cc @stbischof @laeubi @mattrpav 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
