Hi, yes --validate is super costly (see https://gist.github.com/rmannibucau/7e299a729fae276056dbc8c569393cd2 for a sample), 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 (which is more or less as much than enabling annotation processing btw).
onmy side I think for most project it is ok while it can be disabled for "big" ones but happy both ways 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:10, Martin Desruisseaux via dev < [email protected]> a écrit : > Hello Sergey > > Thanks for the checks > > Le 26/08/2026 à 13:07, Sergey Chernov a écrit : > > > - the manifest file now is different, but always specifying the same > "Created-By: > > Maven JAR Plugin 4.0.0-beta-2-SNAPSHOT" (not great, not terrible). > JFYI: > > maven 3 and Gradle by default do no specify this manifest attribute > at all ( > > addDefaultEntries=false) > > I'm not aware of a way to avoid that. Maven 3 and, I presume, Gradle > write the JAR themselves. This pull request delegates to the `jar` tool, > and that tool adds "Created-By" itself if we didn't provided some value. > > > > *Bad news, the PR version of the plugin is approx 2x slower, than the > > current 4.x master.* For my builds it's 7s vs 15s for approx 1000 > > executions (each JAR module). Current 4.x master is just a bit slower > than > > the 3.x version. > > This pull request runs `jar --validate` after it has created the JAR > file (Maven 3 did not). It may contribute to the performance problem you > observed. Can you try the following modification locally and see if it > has an impact on the performances? In the `Archive` class at line 548, > there is a `validate` method. Just replace the method body by an > unconditional `return false;`. It will disable the second pass with `jar > --validate`. > > If there is still a performance gap even after disabling `jar > --validate`, can you post the profiler results saying where the code > spend its time? > > > > One more performance check we need to do - how the new plugin behaves > with > > the immense number of files to be archived. This can be potentially a > huge > > performance issue as well. Did somebody made these tests? > > I have not done the test. But if there is no include/exclude filters, > the plugin just gives the whole directory to the `jar` tool, and the > rest depends on that tool. > > Martin > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
