JDK-8291888 : module export issues with legacy provider registration
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 9
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2022-08-04
  • Updated: 2025-05-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8155246 - Throw error if default java.security file is missing
Description
the JCA framework still supports registration of security Providers via legacy mode which uses the classname/classpath approach.

noticed that a few of the providers that ship in the JDK don't load correctly in this mode. Stumbled across this while working on JDK-8155246

ProviderConfig: Error loading legacy provider sun.security.jgss.SunProvider
java.security.PrivilegedActionException: java.lang.IllegalAccessException: class sun.security.jca.ProviderConfig$ProviderLoader$1 (in module java.base) cannot access class sun.security.jgss.SunProvider (in module java.security.jgss) because module java.security.jgss does not export sun.security.jgss to module java.base
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:575)
        at java.base/sun.security.jca.ProviderConfig$ProviderLoader.legacyLoad(ProviderConfig.java:404)
        at java.base/sun.security.jca.ProviderConfig$ProviderLoader.load(ProviderConfig.java:369)
        at java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:254)
        at java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:248)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
        at java.base/sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:248)
        at java.base/sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:226)
        at java.base/sun.security.jca.ProviderList.loadAll(ProviderList.java:319)
        at java.base/sun.security.jca.ProviderList.removeInvalid(ProviderList.java:336)
        at java.base/sun.security.jca.Providers.getFullProviderList(Providers.java:186)
        at java.base/java.security.Security.getProviders(Security.java:437)


===

ProviderConfig: Loading legacy provider: com.sun.security.sasl.Provider
ProviderConfig: Error loading legacy provider com.sun.security.sasl.Provider
java.security.PrivilegedActionException: java.lang.IllegalAccessException: class sun.security.jca.ProviderConfig$ProviderLoader$1 (in module java.base) cannot access class com.sun.security.sasl.Provider (in module java.security.sasl) because module java.security.sasl does not export com.sun.security.sasl to module java.base
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:575)
        at java.base/sun.security.jca.ProviderConfig$ProviderLoader.legacyLoad(ProviderConfig.java:404)
        at java.base/sun.security.jca.ProviderConfig$ProviderLoader.load(ProviderConfig.java:369)
        at java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:254)
        at java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:248)

======

copy of the java.security properties file that's used in such scenario:

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ssl.SunJSSE
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
security.provider.6=com.sun.security.sasl.Provider
Comments
"legacy" Provider loading is the scenario that fails here. The ServiceLoader and legacy (classpath) loading approach are both described in the java.security properties file. After further chats with dev, it's not desirable to fix up JDK modules to export packages to java.base for this purpose. The SL model is the preferred model for the modular JDK. The legacy approach might be maintained for 3rd party providers but perhaps we can change position and say that the legacy provider loading mechanism is not supported for Providers that ship with the JDK.
12-08-2022
Modules that include security providers declare "provides java.security.Provider with ..." in their module description so they will be located and located by ServiceLoader. The fallback could should be able to use that.
09-08-2022