oki, let's disable validate by default then but it also makes hard to justify the drop of the old impl IMHO, we might want to "milestone" it right in terms of comm no?
Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact via linkedin) Le mer. 26 août 2026 à 22:03, Martin Desruisseaux via dev < [email protected]> a écrit : > Hello Romain > > The --hash-modules option is not yet supported in the current pull > request. It needs the current pull request to be accepted first, before > we can start supporting new options. > > The Java module stuffs are not superseded by other solutions. Maven > resolver makes some guarantees mostly at build time and only for Maven > users. Java modules make strong guarantees (JVM refuses to start if they > are violated) at both compile time and runtime, and for all users, not > only Maven users. > > But anyway, we can keep the --hash-modules discussion for later. It is > not part of the current pull request, but it will need this pull request. > > Martin > > > Le 26/08/2026 à 21:12, Romain Manni-Bucau a écrit : > > well hash module looks nice but a bit like module it is superseeded by > > other solution in a delivery chain like maven resolver expected > > checksums (it is better to validate the jar than the module-info since > > it is trivial to patch the jar keeping the module hash) + runtime > > immutability, it is also depending the build setup (so the jar is not > > generically consummable if you validate it before using it). > > > > You inject the hash of downstream jars in upstream jars (app hash in > > lib modue-info if app depends on lib) so it means we should fail the > > build if there is any provided (discussable I guess) or optional scope > > (pretty sure even if there is some ambiguity in maven usage of > > provided vs optional in practise) and option is enabled no? we should > > really only let it go for strictly static applications in terms of > > dependencies (multimodule support in a single maven module being part > > of it). > > > > So agree both are new features but they also need some maven > > integration and not just a flag else we just need to expose the > > scope+type based dependencies as path in properties and let the user > > build the command itself in a generic tool provider plugin, would be > > more relevant. > > There are a lot of cases you are broken by default now if you consume > > standard poms so it will look like you need to use a sandbox for java > > modules if we dont guard it properly. > > > > Not sure the best way to do it but hash module needs more integration > > until I missed it in the PR (possible since it is a bit fat now) or to > > say we dont support it cause we provide other solutions - think both > > are fine, at least short terms and still thinking out loud. > > > > Romain Manni-Bucau >
