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 

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

Reply via email to