Le jeu. 4 janv. 2024 à 10:54, Martin Desruisseaux < [email protected]> a écrit :
> 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". > As explained in previous post it is not always possible cause JPMS enforces constraints which are not always respected. > > > > 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%. > Your vision I guess, mine is the opposite from what I saw in OSS land so let's not move forward in the discussion while both cases are covered we will be fine. > > Martin > >
