RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]
Alex Buckley
alex.buckley at oracle.com
Fri Feb 14 18:06:10 UTC 2020
On 2/14/2020 12:02 AM, Robert Scholte wrote:
> To me having the correct (main) module descriptor should be the ultimate
> goal. People should not be tempted to apply workarounds on this
> descriptor to make things work for tests (even though those module are
> for sure part of the java runtime)
> Especially because of the impact wrong module descriptors would have and
> which cannot be adjusted.
Nowhere else in Java is there the ability to "patch" one declaration by
making further declarations in source code, so I don't think there's a
way forward for a `patch module ...` declaration. I understand that it
looks good when viewed through the lens of testing, where there's
exactly one secondary module declaration (the test module) and it's
tightly scoped to support white-box tests. However, we have to consider
if it's a good idea in general for a module to be defined by parts,
where anyone could throw multiple `patch module foo {..}` declarations
on the module path and have each of them modify the "master" foo module.
The answer is that it's not a good idea: (i) different `requires`
clauses might clash (i.e. read modules which export the same packages),
(ii) one patch might `open` the module while another patch doesn't want
it open (and there's no way to say non-open), and (iii) the content of
packages in the unified module is now determined by the order in which
the "master" module and the "patch" modules are deployed on the module path.
These things are so undesirable that even `--patch-module` is unable to
override module declarations! That said, command line options can have
superpowers that would never be expressible in source code declarations,
so one option might be a `--patch-module-descriptor` option. This would
be orthogonal to `--patch-module`, which deliberately has leaky
classpath-style semantics for its specified content, and that's neither
desirable nor useful here. Within limits, `--patch module-descriptor`
would merge the declaration of the "patch" module into the "master"
module, and fail hard if the limits are broken. What are the limits? A
starting point is the rules for versioned module descriptors in a
modular multi-release JAR --
http://openjdk.java.net/jeps/238#Modular-multi-release-JAR-files -- and
perhaps it's reasonable to allow additional _qualified_ exports in the
"patch" module.
Now, I am not "proposing" `--patch-module-descriptor` for a future JDK.
I am recognizing that certain use cases involve changing a module's
dependences and encapsulation in a tightly scoped way. A different way
to address those use cases would be to ship the logic just described for
`--patch-module-descriptor` in a launcher offered by the test framework
itself. If JUnit creates its own module layer, then it can define module
descriptors at run time how ever it likes. It's not clear to me if
Christian & co. have looked into java.lang.ModuleLayer,
java.lang.module.Configuration, and java.lang.module.ModuleFinder. If
they have, we'd love to hear their experiences. If they haven't, they
should.
Alex
More information about the jigsaw-dev
mailing list