[External] : Re: Could we have --exclude-modules option?

[Alex Buckley]

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.buckley at 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