Aw: Re: The rationale for runtime modularization

[Jochen Theodorou]

> Gesendet: Freitag, 04. Dezember 2015 um 10:43 Uhr
[...]
> Here is however one point I disagree with: Maven does not offer
> compile-time moduarization. Maven only assures that all dependencies are in
> scope but it does not offer any means to cut down this dependency tree to
> the set of classes that a user intends to include.

Now I am not a maven guy at all and I could be wrong here, but on a dependency level there would be excludes. It is of course not as comfortable as what jigsaw has in stock for your scenario and the usage to do what you wants would I think be a bit non-intentional... but "does not offer any means" seems not to be right to me. Since maven 3.2.1 there is also the option to exclude all transitive dependencies. I personally find that being the best version at compile time.

> Just as an example: my
> current work assignment declares a dependency on a framework that defines
> 107 classes. This framework declares (transitive) dependencies that result
> in a total of 7681 classes becoming visible by including this library as a
> dependency. Relevant for the project (the "non-internal API") are however
> only six classes. Without Jigsaw, this results in a 1200% overhead of
> visible classes that can now accidentally be used in my project (via this
> single dependency out of many).

so normally you would make two jars out of this, one as the main jar, the other as transitive dependency. But this will most likely not work in jigsaw, because of the split package problem.
 
[...]
> Despite, if I wanted to offer modularization for my library which is
> currently compiled to Java 6, I would still be in trouble.

If I think of split packages again, you can be in trouble even if you do intend to ignore modularization.

bye Jochen