RFR: 8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option [v2]

[Jaikiran Pai]

On Tue, 17 May 2022 13:08:32 GMT, Adam Sotona <asotona at 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