<div dir="ltr"><p><span>Hello,</span></p><p><span>I recently added support for module layers in my library and encountered a limitation. It appears that reading resources from custom layers is not fully supported. As a result, annotations on modules are not visible from my layers.</span></p><p><span>My implementation uses a custom module reader that stores module data in memory and does not rely on file paths. When reading annotations from a module-info.class, the internal logic loads the class representation, locates the module’s loader (jdk.internal.loader.Loader), and calls URL findResource(String </span>moduleName<span>, String name) on that loader.</span></p><p><span>From my original loader, the correct URL would be available. However, Loader looks up the ModuleReference, retrieves the ModuleReader, and calls Optional<URI></span><span> find(String name). The URI is returned, but since it is not possible to attach a resource handler directly to a URI, the resolution fails when converting to a URL. Everywhere else, the Layer mechanism uses Optional<InputStream></span><span> open(String name), which avoids this indirection through a URL such that I can return the right byte representation for all resources.</span></p><p><span>Technically, this could be resolved if ClassLoader had a method like getResourceAsStream(String moduleName, String name), allowing the Layer to invoke ModuleReader::open. This would be consistent with the other extension. Would such an extension and a change of internal use be considered viable?</span></p><p><span>Thank you for your time and consideration.<br>Best regards, Rafael</span></p><br></div>