RFR: 8331081: 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version
Jan Lahoda
jlahoda at openjdk.org
Thu May 2 20:34:54 UTC 2024
On Thu, 2 May 2024 19:23:11 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:
> This change fixes a bug preventing javac from emitting 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a non-default value. The diagnostics are currently emitted for values of `--release`, and for the default value of `--system`.
Traditionally, I don't think javac was ever (supposed to) produce these warnings when the system classes where overridden (using `-bootclasspath` in JDK <9, and `--system` in JDK >= 9).
I believe the idea was that when someone provides their own the system classes, we shall not produce a warning based on some hardcoded knowledge, which may or may not be relevant for the externally provided system classes. That might be overly cautious, especially given that since JDK 9, it is only about `jdk.unsupported`, and it is harder to imagine a usecase where the warning would not be reasonable for that module.
On the code level, I would suggest to re-organize the code so that user packages would not accumulate in `supplementaryFlags` - that seems unnecessary. If the module owning `c` is neither `noModule` nor `jdk_unsupported`, there's no point in putting anything in the map the computation, I think. (Not too terrible, but some user programs use a lot of packages.)
Also, I wonder why not simply use `--release 11`. The set of usecases for which `--system` needs to be used instead of `--release`, and for which the warning is important seems quite limited to me.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19069#issuecomment-2091505508
More information about the compiler-dev
mailing list