On Wed, 18 May 2022 02:50:49 GMT, Jaikiran Pai <j...@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
