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 @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 à 18:52, Martin Desruisseaux via dev < [email protected]> a écrit : > Le 26/08/2026 à 18:32, Romain Manni-Bucau a écrit : > > > since it is the only reason we moved to jar tool provider we might > > ask ourselves if we keep this choice or drop it if we consider being > > ~=>100% slower is too much > > Validation is not the only reason for moving to the jar tools. Other > options are --hash-modules, --main-class (in a modular JAR, it updates > `module-info.class`, easier debugging and (as an opportunistic gain) > toolchain support. Another work which is not directly related to the jar > tool but is also in the pull request is the multi-modules support. > > The easiest fix is to add a `validate` configuration option and run `jar > --validate` only if requested. > > Martin > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
