Static module requirements are treated as normal requirements

[LoadingByte]

First of all, thank you for this incredibly useful plugin! It really eases modularizing an app where a couple of the dependencies are still non-modular.

I noticed a bit of peculiar behavior and I'm not sure whether it's intended or a bug:

Let's say that the dependency "A" of my project is a modular JAR and itself declares requires static on a JDK module "J". Then your plugin includes "J" in the jlinked image if and only if the bytecode of "A" has any reference to classes exported by "J".

I find this surprising for two reasons:

• Even though "A" is a modular JAR, your plugin scans its bytecode to determine whether it references "J". I would expect that if a JAR is modular, all requirement information is contained in its module descriptor, and hence no scanning is necessary.
• From a semantics perspective, "A" declaring requires static means that "J" is optional, and hence the consumer of "A" can choose to omit "J" if he is ok with loosing some functionality. Your plugin follows exactly this expected behavior, but only if there is no explicit reference to "J" in the bytecode of "A". That feels inconsistent, since some optional requirements might be realized via reflection (in which case your plugin omits "J"), while others might be realized via actual bytecode references (in which case your plugin includes "J").

I've set up a working example that illustrates the behavior here:

static-requirement-sample.zip

projA is module "A" and has a static requirement on java.desktop, which is module "J".

You first need to run ./gradlew build in projA, and then ./gradlew jlink in projB. Then you'll have a jlinked image that includes java.desktop.

When you comment out the call to new Point() in projA/src/main/java/pkgA/ClassA.java and re-run the above commands, the jlinked image no longer includes java.desktop.

I hope you can shine some light on whether this unexpected behavior is a bug or intended.