...check it out again but you also said "it does not work" so still not, as soon as one lib is not jpms compatible (not by not being a module but by not being consummable even with implciit name as explained in this example) you can't use jpms first but you can always workaround the other way around so from a theorical standpoint classpath has still a wider area - not saying it is better to always start with classpath though, don't overinterpret please.
But anyway we can move forward we don't have to agree on that Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 4 janv. 2024 à 17:19, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-04 à 17 h 01, Romain Manni-Bucau a écrit : > > > We didnt speak of that but consuming that in a classpath/module > > friendly project. > > > This part was answered: build as JPMS + workarounds. The > counter-argument was that it should be built as class-path + workarounds > instead, which I tried to demonstrate by test cases that it doesn't > work. JPMS + workaround is the only sane way (to my knowledge) to build > a lib that can be consumed on both the classpath and the module-path. > > Martin > >
