Checking if APR is available logs a warning on Java 24

[wilkinsona]

WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by org.apache.tomcat.jni.Library in an unnamed module (file:/Users/aw036093/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-core/10.1.34/f610f84be607fbc82e393cc220f0ad45f92afc91/tomcat-embed-core-10.1.34.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

The above is triggered within org.apache.catalina.core.AprLifecycleListener.isAprAvailable(). It occurs whether or not APR is available. We should do something about this as part of adding support for Java 24. We could:

1. Make adding the APR lifecycle listener opt-in
2. Make adding the APR lifecycle listener opt-in on Java 24
3. Try to detect --enable-native-access and only add the listener when it's set

1 would be a breaking change for those who're already using APR. 2 wouldn't break any existing deployments as a Java 24 upgrade would be required to see a change in behavior. 3 might not be possible and, even if we can detect the flag, knowing that the module name's correct might not be possible. 2's perhaps the least bad option. If we did that for 3.4.x we could then perhaps make it opt-in for everyone in 3.5.

I'd like to see what the rest of the team thinks.

[wilkinsona]

As part of addressing this, we should remove --enable-native-access=ALL-UNNAMED from LoaderIntegrationTests for both loaders when using Java 24.

[markt-asf]

Another option is to drop APR when running on Java 24 (actually Java 22) onwards and use the org.apache.tomcat:tomcat-coyote-ffm module. That is set up with the org.apache.catalina.core.OpenSSLLifecycleListener.

[philwebb]

We're going to look at option 2 from Andy's list, but we need to think of a good property name. Tagging as pending-design-work until we do that.

[mhalbritter]

I have some changes in this branch which adds a server.tomcat.apr property. Its default value is AUTO_DETECT, which means:

on Java < 24: Calls AprLifecycleListener.isAprAvailable
on Java >= 24: Same as NOT_AVAILABLE

You can also use AVAILABLE (enable APR) or NOT_AVAILABLE (disable APR).

WDYT?

[wilkinsona]

I think AUTO_DETECT might be confusing. Would someone using Java 24 who's enabled native access expect that to be detected and for APR to be enabled?

[mhalbritter]

That's clarified in the JavaDoc of that property - it only works on Java < 24, on Java >= 24 it's equal to NOT_AVAILABLE.

[wilkinsona]

That may help when writing the configuration in an IDE that makes use of the metadata. When reading it, I still think it might be confusing unfortunately.

I'm not sure that this is that much better, but what about spring.tomcat.use-apr with values never and when-available? We could also support always and fail in the absence of APR.

The ideal would be that we default to never across the board and I think we could do that for 3.5. For 3.4, the default would be when-available for Java <= 23 and never with Java > 23. I find it slightly better for the Java-version-specific behavior to be in the property's default than in the meaning of one of the values. It allows us to get rid of the difference more easily in 3.5.

[mhalbritter]

With 3.4.4, server.tomcat.use-apr defaults to NEVER when running on Java >= 24 and to WHEN_AVAILABLE on Java < 24.

With 3.5.x, server.tomcat.use-apr defaults to NEVER regardless of the Java version used.

I've added something to the upgrade notes.