Extend ClassLoader API for better support of custom ModuleReader?

[Rafael Winterhalter]

Hello,

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.

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 moduleName, String name) on that loader.

>From my original loader, the correct URL would be available. However,
Loader looks up the ModuleReference, retrieves the ModuleReader, and calls
Optional<URI> 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> open(String name), which avoids this indirection
through a URL such that I can return the right byte representation for all
resources.

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?

Thank you for your time and consideration.
Best regards, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20251103/62affa39/attachment-0001.htm>