Red Hat Bugzilla – Bug 959478
Add sun.nio.cs & sun.nio.ext paths to sun.jdk module
Last modified: 2013-12-15 11:55:40 EST
Description of problem: sun.nio.cs & sun.nio.ext paths are not exposed in sun.jdk module, which causes an issue when we try to load a custom character set using ServiceLoader Version-Release number of selected component (if applicable): EAP 6.0.1 / EAP 6.1.0 Beta1 How reproducible: Steps to Reproduce: 1. java.util.ServiceLoader.load(java.nio.charset.spi.CharsetProvider.class) Actual results: Caused by: java.util.ServiceConfigurationError: java.nio.charset.spi.CharsetProvider: Provider sun.nio.cs.ext.ExtendedCharsets not found at java.util.ServiceLoader.fail(ServiceLoader.java:214) [rt.jar:1.6.0_24] at java.util.ServiceLoader.access$400(ServiceLoader.java:164) [rt.jar:1.6.0_24] at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:350) [rt.jar:1.6.0_24] at java.util.ServiceLoader$1.next(ServiceLoader.java:421) [rt.jar:1.6.0_24] Expected results: No exception
The simple workaround is to use the variant of ServiceLoader.load() which accepts a class loader, and pass in null. In fact this is almost always the right way to load things when you know they're part of the JDK.
Created attachment 747944 [details] Project with WAR to demonstrate the problem
In this particular case we don't want to load a class from the JDK, but we created our own charset. But JBoss includes <path name="META-INF/services"/> in modules/sun/jdk/main/module.xml. Therefore it loads META-INF/services/java.nio.charset.spi.CharsetProvider from jre/lib/charsets.jar. But then it can't find sun.nio.cs.ext.ExtendedCharsets since this path is not included in the module. So it throws an exception before it gets to the custom service. In my opinion sun/jdk/main/module.xml is not consistent. Either it should not include META-INF/services, or, if it does, it has to include the classes that are referenced in the extensions.
OK that makes sense.
Added dev_ack+ on behalf of David.
I don't think this has been fixed correctly. Specifically, I belive that there is no such package as "sun.nio.ext" -- instead, it should have been "sun.nio.cs.ext". Moving back to assigned. On the other hand, I admit I'm not expert in this area, so I'd like to be proven wrong :-)
I took the liberty to fix this myself. Here's the upstream pull request: https://github.com/wildfly/wildfly/pull/5259
Verified with EAP 6.2.0.ER6.