Resource API

[dmlloyd]

Proposed resource API. Provides a uniform API for reading resources from the class path or filesystem.

Non-goals are presently including:

• Support for writing

[geoand]

Very cool!

I think a follow up with a loader API would be most useful too

[dmlloyd]

I'm making some changes based on wanting a resource loader API as well (adding a canonical relative path to Resource with supporting helpers). I'm going to make this particular submodule require 17+, since it is new code (there is no compatibility risk).

[radcortez]

Once we get the new Resource Loader API, should we deprecate ClassPathUtils or rewrite it to use the new APIs?

[dmlloyd]

Good question. I'll see if rewriting them with the new APIs is feasible and I'll probably have a better answer then.

[dmlloyd]

OK, here's where we stand with this.

We have Resource, which represents a resource (obviously). You can open a stream from it, get its URL, get its size, get its last-modified time, and get its relative path (which is always canonical by an efficient algorithm, and thus cannot "escape" via ..). If it's a directory, and if the impl supports it, you can iterate the resources in the directory. You can also get a buffer containing the entire contents of the resource, and also get the resource contents as a single string.

There are implementations for JAR file entries, URLs, Path, and memory-backed resources. The memory-backed resource API is future-proof relative to FFM and MemorySegment. The Path-backed API supports mmap of large resources.

Then there's the ResourceLoader interface, which allows you to find a resource given a path relative to the root of the loader. There are resource loader implementations for JAR files (future proof against a possible future port of wildfly-common's "archive" implementation, which supports mmap of JAR files), Path, and URLs.

It should be possible to reimplement (or replace our usages of) ClassPathUtil with this API. However, that module requires Java 11, so we'd have to also bump up the minimum runtime version of that module to 17 (which should be OK since I don't think WildFly is using this API at all). I think a logical next step would be to consider doing so, and then after that, to consider adding a base ClassLoader implementation which can easily make use of resources and resource loaders in some efficient manner.

[radcortez]

It should be possible to reimplement (or replace our usages of) ClassPathUtil with this API. However, that module requires Java 11, so we'd have to also bump up the minimum runtime version of that module to 17 (which should be OK since I don't think WildFly is using this API at all).

We use it in SmallRye Config (and maybe other SmallRye projects are using it too). We had some discussions about moving SmallRye to Java 17 a few months ago, and we decided to wait a little longer. We probably need to revisit that discussion.

[dmlloyd]

It should be possible to reimplement (or replace our usages of) ClassPathUtil with this API. However, that module requires Java 11, so we'd have to also bump up the minimum runtime version of that module to 17 (which should be OK since I don't think WildFly is using this API at all).

We use it in SmallRye Config (and maybe other SmallRye projects are using it too). We had some discussions about moving SmallRye to Java 17 a few months ago, and we decided to wait a little longer. We probably need to revisit that discussion.

I can wait on ClassPathUtil; it's definitely not urgent to change that API. Another option we have is to move Quarkus over to the new API, and deprecate ClassPathUtil and leave it until nobody is using it anymore, and then just drop it in favor of the new API. But we don't have to do anything right away.