On Tue, 17 May 2022 13:08:32 GMT, Adam Sotona <asot...@openjdk.org> wrote:
>> ### Problem description >> Minimal jdk image created by jlink with the only jdk.compiler module and its >> dependencies >> fails to run java source launcher correctly (for example when --source N is >> specified). >> Failing source launcher is only one the expressions of internal jdk.compiler >> malfunction, another example is failure to run javac with --release option. >> >> ### Root cause >> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse >> ct.sym file and so to provide full functionality. >> Module jdk.zipfs is not included in the minimal JDK image, because module >> jdk.compiler does not declare it as "requires" in its module info. >> >> ### Alternative patch >> The problem can be alternatively resolved by complex code checks in >> jdk.compiler to provide user with valid error message, however that solution >> would be just a workaround for jdk.compiler dual functionality (with or >> without presence of jdk.zipfs module). Compiler functionality without access >> to ct.sym through jdk.zipfs is very limited. >> >> ### Proposed fix >> This patch fixes the problem by explicit declaration of jdk.compiler >> dependency on jdk.zipfs. >> Plus added specific test case. >> >> Please review the patch or raise objections against declaration of >> jdk.compiler dependent on jdk.zipfs. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional > commit since the last revision: > > fix of LimitedImage test Hello Adam, I don't have necessary knowledge of this area, so I don't know what approach would be preferred. But a couple of questions: - If we do decide to add the `jdk.zipfs` dependency to `jdk.compiler` module, do you think the `LimitedImage` test is still relevant? Or should it be removed? The comment on that test states: > @summary Verify javac behaves properly in absence of zip/jar > FileSystemProvider and it does so by using `--limit-modules`. But now with the `jdk.zipfs` being a dependency, the zip/jar FileSystemProvider will not be absent and the test then would seem unnecessary. - In the JBS issue corresponding to this PR, you noted that: >There are actually two different issues: > >First in JDKPlatformProvider, which silently swallows >ProviderNotFoundException. Should something be done there? I see that the catch block happens to reside in the `static` block of that class (which also happens to be a implementation of a Java `service`), so I'm unsure what if anything can be done there. ------------- PR: https://git.openjdk.java.net/jdk/pull/8747
