On Tue, 24 Mar 2026 15:31:38 GMT, Alan Bateman <[email protected]> wrote:
> ServiceLoader specifies its iterator methods to throw
> ServiceConfigurationError (SCE) when there is an error locating, loading or
> instantiating a service provider.
>
> There are linkage error cases where the LinkageError is propagated rather
> than throwing SCE with the LinkageError as cause. These typically arise in
> "bad environments" such as a mismatch between compile-time and run-time,
> missing dependencies, or maybe instrumentation/injection that has modified
> classes with references to classes that are not visible at run-time.
>
> The behavior for these cases has varied a bit over time. Since JDK 9 (when
> ServiceLoader was significantly re-implemented), a LinkageError thrown by
> Class.forName when attempting to load a service provider class is propagated
> without throwing SCE. Since JDK 24 (when support for the security manager was
> removed), if getting the no-arg the constructor triggers class loading and a
> LinkageError is thrown then is propagated without throwing SCE.
>
> The proposal here is to change the implementation to throw SCE consistently
> for these cases. This would be observable change so there is a CSR to review
> the impact.
>
> One of the existing tests for "bad" annotation processors needed to be
> updated to handle the ServiceConfigurationError as that test had worked
> around the issue and was handling the cause instead.
test/jdk/java/util/ServiceLoader/linkageerrors/LinkageErrorsTest.java line 111:
> 109: * provider class names.
> 110: */
> 111: private void createServicesonfigFile(Class<?> service,
Suggestion:
private void createServicesConfigFile(Class<?> service,
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30405#discussion_r3058050353
