Le 2024-01-04 à 10 h 27, Romain Manni-Bucau a écrit :
You also explained this is not true since you cannot compile part of
the code linked to optional depswhich go against JPMS
No, optional dependencies in JPMS are handled by "static requires".
You will also note the compile time check is a very low check in this
area compared to any runtime (tests) so this is a sacrifice which is
generally very acceptable
This statement is highly questionable. But anyway, this is an
unnecessary sacrifice as it requires going the hard way (trick Java).
the ecosystem is far to have adopted it and it does not bring much to
dev, so please don't assume JPMS is the way to go *yet*.
I'm not forcing anyone to use JPMS. I'm trying to make it easy for those
who want.
* Want class-path compatibility only? Compile on class-path.
* Want JPMS compatibility only? Compile on module-path.
* Want JPMS + class-path compatibility? Compile on module-path +
workarounds. There is no sane alternative.
doing anything classpath + workarounds for JPMS works in 90% of cases
No, this approach requires tricking Java and is unsafe, for no gain in
the end result compared to the simple and sane way. Furthermore, it does
not work at all (uncompilable) for the common case where the developer
wants to write module-info.java himself. It does not cover 90% of cases,
it is more like 1%.
Martin
