[BUG] Module descriptor seems overkill

[io7m]

Describe the bug

In choco-solver 4.10.10, the module descriptor contains the following definitions:

    requires trove4j;
    requires org.jgrapht.core;
    requires java.desktop;
    requires org.knowm.xchart;
    requires java.management;
    requires automaton;

This means that, even if I'm using none of the above - if I'm just using choco-solver as a pure solver and don't need graph rendering, chart rendering, and etc - well, tough. I have to ensure that all of those modules are present at run-time or the JVM will refuse to boot. For example, excluding xchart will result in:

Error occurred during initialization of boot layer
java.lang.module.FindException: Module org.knowm.xchart not found, required by org.chocosolver.solver

Are all of these really needed? I can't even find references to xchart in the jar file.

To Reproduce

Look in the module descriptor. :)

Expected behavior

I'd like to see only those dependencies that are strictly required be present in the module descriptor.

Possible solution

Optional dependencies should be moved to separate jar files and/or encapsulated in services with ServiceLoader.

Screenshots

Environment (please complete the following information):

<dependency>
  <groupId>org.choco-solver</groupId>
  <artifactId>choco-solver</artifactId>
  <version>4.10.10</version>
</dependency>

openjdk version "17.0.7" 2023-04-18
OpenJDK Runtime Environment (build 17.0.7+7)
OpenJDK 64-Bit Server VM (build 17.0.7+7, mixed mode)

Additional context

[cprudhom]

Hi

Thank you for the feedback and suggestions. First, to answer your question:

Are all of these really needed?

• trove4j is used in various places (constraints, propagation engine, etc.). We use it intensively, or at least a few implementations.
• org.jgrapht.core and automaton are required for CostRegular and MultiCostRegular constraints.
• java.desktop, org.knowm.xchart and java.management are required for StatisticsPanel, callable via solver.showDashboard(long). I suppose these might be optional.
• sizeof (added in 4.10.11) is required for model.getEstimatedMemory().

Then about solutions:

Optional dependencies should be moved to separate jar files

To be honest, I'm trying (somewhat) to simplify my life and that of non-advanced users, so I'm trying to limit the number of jars and the configuration. The option of having 2 jars and explaining in which situations you should use one rather than the other bothers me a bit. This one of the reasons there is now only one jar available on GitHub. So this solution doesn't appeal to me all that much but I admit that it's not an overwhelming argument.

encapsulated in services with ServiceLoader.

I've never considered this option, which, at first glance, seems to me to be a very attractive one. This echoes the single jar from the previous point. (Since 4.10.9, the maven-shade-plugin is used to remove useless inherited dependencies, such as com.ibm.icu:icu4j, org.apache.pdfbox and org.apache.fontbox but that is another point).

So, I will have a look at this solution, probably create a PR and let you know.

[cprudhom]

Thinking about it twice, since java.desktop and org.knowm.xchart are only required for a pure java graphical display. But no doubt it could be part of a complementary project, aimed solely at displaying resolution statistics, probably in a hybrid java/JS project.

[cprudhom]

An in-between solution would be for choco-solver to offer the ability to connect to a server and send messages (via socket, WebSockets, RESTful API or gRPC). However, this would require dependency.

[io7m]

I have to admit to not knowing how that part of the code works internally, but I feel like a more standard way to handle that would be to expose something to which external code can subscribe. Maybe something like a Flow.Publisher that publishes events. The graphical display can then be a separate component that depends on the core, and not the other way round.

[io7m]

Thanks for doing that. Very quick work!