A DESCRIPTION OF THE PROBLEM :
Creating a jar file with the -M flag ("does not create a manifest file entry") appears to cause jar(1) to add extended attributes to the last file added to the archive. As files are not added to a .jar in a deterministic order (if, say, a directory is specified on the command-line, it inherits the ordering of the underlying filesystem), this means that even if the files are subsequently sorted by some other tool (I comaintain such a tool), the extended attribute is moved around independent to this hypothetical resorting. This means that jar files created with -M are nondetermistic / non-reproducible

This was first seen in the Debian threeb package: https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/issues/19

I'm not quite sure what is being stored in this extended attribute (is it required? is it a millisecond timestamp as the source seems to imply?), but oen solution would be to always sort files being added to the jar.

Here is the extended attribute (bX in zipinfo output):

$ zipinfo -l a.jar | grep -i bX
-rw---- 2.0 fat 2977 bX 1587 defN 22-May-04 05:04 AdvancedDialog.class

$ zipinfo -l b.jar | grep -i bX
-rw---- 2.0 fat 4448 bX 2487 defN 22-May-05 07:05 three_B.class


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
jar cvf output.jar -C path-to-dir/ .

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Identical result regardless of underlying filesystem ordering.