Re: Rewrite of JAR plugin ready for merge

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]
>
>