[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR: 8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with -
From:       Jaikiran Pai <jpai () openjdk ! java ! net>
Date:       2022-05-18 2:53:49
Message-ID: nrGBwA6vmG_fJoHfhXkK90t94mEseybWdkeYC5QAxiw=.109d7fb0-9fd8-4e11-a03e-b796c78d3e5e () github ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]