IllegalAccessError for package-private member of AzureStorageConfiguration on WebSphere

[sachinkumar579]

Getting an exception after upgrading from Spring boot 3.3.8 to 3.3.9 .

Caused by: java.lang.IllegalAccessError: Class 'com.azure.spring.cloud.autoconfigure.implementation.storage.AzureStorageConfiguration$$SpringCGLIB' illegally accessing package-private member of class 'com.azure.spring.cloud.autoconfigure.implementation.storage.AzureStorageConfiguration'
at com.azure.spring.cloud.autoconfigure.implementation.storage.AzureStorageConfiguration$$SpringCGLIB.()

spring-cloud-azure-dependencies : 5.19.0
Java : A custom image built on websphere-liberty:kernel-java17-openj9

Please note it seems to be working fine with OpenJDK 17 .

Since Spring framework is responsible for creating CGLib proxies for configuration classes , posting it here.
Spring Framework 6.1.17 version shipped with Spring Boot 3.3.9. Previous spring boot version 3.3.8 had Spring Framework 6.1.17, which seemed to work fine .

[jhoeller]

When exactly is that exception being thrown? Could you post the full stacktrace, at least to the degree that Spring is involved? Is this about a package-visible @Bean method?

Also, what's the different ClassLoader involved? The CGLIB subclass is being generated into a different ClassLoader than the original user class in such a scenario.

In any case, this looks like a regression caused by #34274. We'll see what we can do about using the original ClassLoader of the configuration class in such a scenario, as we did before.

[jhoeller]

@sachinkumar579 I have not been able to locally reproduce this yet. As you say, it seems to be working fine on OpenJDK/HotSpot, with the package visibility check happening at a different point there. It'd be great if you could provide the stacktrace for that IllegalAccessError indeed, otherwise it's hard to consider what we can do to be equally defensive on OpenJ9 as well.

[jhoeller]

I've added an explicit check for package visibility, always defining the generated subclass in the same ClassLoader as the original user class then. This is the only way to guarantee that package visibility works consisently: within the same ClassLoader. Previously, we relied on CGLIB class generation to fail in that case but apparently it does not fail consistently there, potential causing errors later on.

[jhoeller]

This is available in the latest 6.2.6 and 6.1.19 snapshots now. Please give it an early try and let me know whether it works for you!