HHH-14858 - Implement JRT Module Readers

[GedMarc]

This PR allows reading the JRT virtual file system, which uses a new URL format structure to reference to files located in the module VFS

[hibernate-github-bot]

Thanks for your pull request!

This pull request does not follow the contribution rules. Could you have a look?

❌ All commit messages should start with a JIRA issue key matching pattern HHH-\d+
    ↳ Offending commits: [5273cc5, d21a026, 6eb0210]

› This message was automatically generated.

[sebersole]

I don't know much about the JRT format, but lgtm

[yrodiere]

Maybe a test would be a good idea? :)

[GedMarc]

Yeah definitely - difficult to do though as you need a 100% module-info chain to create a native runtime, and gradle is not quite there yet with jlink, jpackage and jmod support

Hmm, can fong the test though, as it's just a URL handler with a string extract - will get one in for you @yrodiere, but without building a JLink/JMod package, you never see the JRT filesystem ;) Would this be acceptable or do we need a non-flaky non-fudged test xD

Can I do something like we did for Jackson? (https://github.com/FasterXML/jackson-jdk11-compat-test)

I had to create a separate project that builds up the JLink artifact, and then executes the tests through the native runtime to replicate all JRT related issues (being a fully read only filesystem)

[yrodiere]

That seems awfully complicated; no, I don't think this is worth creating a new module and trying to use jlink.

But jrt:/ URLs only require your test to run in the modulepath, right? You don't need jlink, native compilation, or anything like that?

There already is a module that runs tests in the modulepath: hibernate-integrationtest-java-modules. So you could just add a (unit) test in hibernate-integrationtest-java-modules/src/test/java. I would keep it simple: just instantiate JRTInputStreamBasedArchiveDescriptor, pass it a jrt:/ URL to a random module that you know will be in the modulepath, and check that it collects an entry that you know should be there.

Maybe that won't reliably test that your use case is addressed, but at least this will check that your implementation successfully retrieves entries from jrt:/ URLs.

[GedMarc]

I definitely agree with you that's it is awfully complicated :)
The JRT only exists for native runtimes, so JLink etc, no other way to access that VFS or use/create the jrt:// urls that I know of ;)
Under class path mode (or loose module mode, a.k.a. not a physical module distribution but running off JAR's instead of compiled JMOD's), the JRT system isn't even included as loaded on a JDK (cause you can't use the new fast-class constructor, the new SPI service, resource finder etc and all the other pretty things that come with native modules and do not operate or even load with classpath/jar files)

What we are looking at here is similar to this https://stackoverflow.com/questions/54140750/java-nio-cant-read-files-from-jrt-image - except it's a jar archive read instead of an Io resource read

I'm creating a URLStreamHandlerProvider that will fudge the JRT URL and locate accordingly in a jar file, that will at least give us an authentic test on the URL handling and reading :)

[GedMarc]

recreating under correct commit strategy with test cases