Apache Aries Activator needs updates to accommodate changes in OpenJ9 OpenJDK 17

[jimmy1wu]

I am testing with an early Semeru 17 development driver and I am getting the following error on server shutdown.

[9/4/25, 14:45:02:301 PDT] 00000046 com.ibm.ws.security.ready.internal.SecurityReadyServiceImpl  I CWWKS0009I: The security service has stopped.
[9/4/25, 14:45:03:600 PDT] 0000001b LogService-165-com.ibm.ws.org.apache.aries.jndi.core         E CWWKE0701E: FrameworkEvent ERROR org.osgi.framework.BundleException: Exception in org.apache.aries.jndi.startup.Activator.stop() of bundle com.ibm.ws.org.apache.aries.jndi.core.
	at org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:916)
	at org.eclipse.osgi.internal.framework.EquinoxBundle.stopWorker0(EquinoxBundle.java:1080)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.stopWorker(EquinoxBundle.java:399)
	at org.eclipse.osgi.container.Module.doStop(Module.java:699)
	at org.eclipse.osgi.container.Module.stop(Module.java:557)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.decStartLevel(ModuleContainer.java:2153)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:2022)
	at org.eclipse.osgi.container.SystemModule.stopWorker(SystemModule.java:281)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.stopWorker(EquinoxBundle.java:225)
	at org.eclipse.osgi.container.Module.doStop(Module.java:699)
	at org.eclipse.osgi.container.Module.stop(Module.java:557)
	at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:212)
	at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:244)
	at java.base/java.lang.Thread.run(Thread.java:853)
Caused by: java.lang.IllegalStateException: Error setting field: no field found for type interface javax.naming.spi.ObjectFactoryBuilder
	at org.apache.aries.jndi.startup.Activator.swapStaticField(Activator.java:330)
	at org.apache.aries.jndi.startup.Activator.stop(Activator.java:269)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:896)
	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:757)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:888)
	... 13 more
 Event:org.osgi.framework.FrameworkEvent[source=com.ibm.ws.org.apache.aries.jndi.core_1.1.106.202509032037 [165]] 

Investigations lead to this commit in openj9-openjdk-jdk17 which moved the object_factory_builder field of typeObjectFactoryBuilder from NamingManager to NamingManagerHelper, which is causing the above error to occur.

Judging by this piece of code in our Activator overlay, it seems like we've encountered this issue before with Java >= 20.

We'll need to update the overlay to accommodate this change in 17 as well. I don't see this error with the latest Semeru 17.0.16, but I think it will start occurring on the next release. I only see this now because I am working with a early development driver from Semeru team.

We may need to figure out a way to have the Aries JNDI factories register with the kernel set one so that it doesn't have to use these reflection tricks.

[arkarkala]

We need this driver for our FIPS 140-3 support so should be high priority. It looks like this was an issue with JDK 21+ which had been fixed and can be extended to Java 17 too. That update seem to work but @tjwatson wanted to look into this more based on this slack conv.

I think we may need to figure out a way to have the Aries JNDI factories register with the kernel set one so that it doesn't have to use these reflection tricks.
I had to do similar things for the URL handlers in Equinox.

I have ideas on how to do that, but will need an issue opened to prioritize working on that over what I am currently doing.

[tjwatson]

@jimmy1wu merged a fix that should get us passed the immediate concern. I do think we need to consider an approach that avoids the deep reflection into the JVM. But that probably needs a larger (maybe Epic) to discuss/prioritize.

I am concerned about the state of this issue because it is for a potential future release of Java. I am tempted to make it a release bug so we can record the Liberty release it is fixed in for cases where a user has an older version of Liberty but updates their Java version to a version that causes the error.