Le jeu. 4 janv. 2024 à 10:20, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-04 à 09 h 21, Romain Manni-Bucau a écrit : > > > Please just stip thinking jpms first, think classpath first with jpms > > compat, changes the whole perspective. If i want classpath compat more > > than jpms why would i do everything with module and miss my 80% case? > > > Because doing everything as JPMS + workarounds (e.g. copying service > declarations into META-INF) works in both cases (proof: the Apache SIS > project), while the converse is not true: you cannot compile a JPMS > project with class-path, except by tricking Java (inject module-info > *after* compilation, at the cost of sacrificing compile-time checks in > the whole project). > You also explained this is not true since you cannot compile part of the code linked to optional deps which go against JPMS so status quo there and no single silver bullet. 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 until you are JPMS first which is still quite rare - I don't want we emphasis JPMS more than its adoption, this is not because tools are not ready that it is not adopted just because the programming model is not nice enough, 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* - hopefully it can be enhanced in the future on java platform but it is way outside build scope IMHO. So overall doing anything JPMS + workaround works in 80% of cases, doing anything classpath + workarounds for JPMS works in 90% of cases or something like that so it is literally a dev/community preference IMHO and you can't impose one or the other with technical points (depends how much you use optional deps, the existing code base, the compilation base also, etc...). Let's just make it all working as smoothly both ways. > > Martin > >
