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

Adam Sotona asotona at openjdk.java.net
Wed May 18 06:21:50 UTC 2022


On Wed, 18 May 2022 02:50:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> 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.

You are right, the test description should change. The test name is LimitedImage and it verifies that javac behaves properly in limited JDK image. I think the purpose of the test is still the same, just results are different (now it pass compilation instead of failing with specific error).

Thanks for pointing it out.

> 
> * 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.

Silent swallow of an exception in static initializer of a service is not very good practice and it has significant effect on this issue right now. However it will express itself only in corner cases (like for example broken ct.sym file) after this patch is integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8747


More information about the compiler-dev mailing list