On 8/9/2022 2:23 PM, Andrejus Chaliapinas wrote:
Are these two JARs built from code you control?
No, they are all Open Source
Are they third-party dependencies of your application, or fourth-party?
Also, what did their maintainer say when you pointed out the existence
of split packages, and how they make it difficult to use the JARs as
automatic modules?
When you're faced with code that's aggressively unmodular, it seems
attractive for the JDK to come swinging to the rescue with a power-user
command-line option to tweak the environment just so. But these options
accumulate in scripts (and then get forgotten about), and they interact
with other options in surprising ways that generate new requests for
further tweaks. Options that duplicate functionality found outside the
JDK (e.g., --exclude-modules vs. POM <exclusions>) impose an even bigger
cost, as people need to understand the differences, get confused when
the option doesn't work like the external tool, etc. The best and most
maintainable path is to fix the legacy JARs so they work cleanly as
automatic modules.
Alex
If not, then trying to
figure out if your application "works" when only JAR1 is present, or
only JAR2 is present, sounds difficult.
It's actually not difficult - set of tests runs over and checks runtime
behaviour. And passing extra argument to either Surefire for UTs or Failsafe
for ITs/etc. plugins configs is trivial.
And introducing
--exclude-modules to "fight" the dependencies resolved by Maven is a bad
idea.
I see this option as extra flexibility for complex projects. It's not about
"fight" here, but about fast way of figuring out what is actually
needed/suitable and allowing gradual migrations. Cause dealing with Maven exclusions in
POMs (even if that is final goal to fully eliminate conflicts) is more difficult till
some extent.
One side use case here is presence of jars with key word in their names (like "byte" or
"native"), which are invalid from Java modules angle, but quite often are yet Automatic
as not migrated to support Java modules. So then workaround is either injecting extra Manifest
entry by some Maven plugin or renaming overall jar. Both activities are less trivial comparing to
proposed option.
Andrejus
On Tuesday, August 9, 2022, 10:03:56 PM GMT+1, Alex Buckley
<alex.buck...@oracle.com> wrote:
On 8/9/2022 1:07 PM, Andrejus Chaliapinas wrote:
Have you tried java --validate-modules? This option will scan the
module path split package for other issues so that you get a dump of all
issues.
Yes, that was my starting point, i.e usage of --validate-modules. But
seeing outcome of it for complex dependencies set led to this my
proposal actually. Cause validate shows conflicts, but elimination of
them takes effort via build tooling configs. And much easier would be
initially to evaluate runtime outcome via flexible exclusion capability
(i.e. in a way we have for Maven dependencies exclusions for example).
Are these two JARs built from code you control? If not, then trying to
figure out if your application "works" when only JAR1 is present, or
only JAR2 is present, sounds difficult. And introducing
--exclude-modules to "fight" the dependencies resolved by Maven is a bad
idea.
Alex
