Generated JAR file depends on default time zone

[ppkarwasz]

When Moditect adds elements to an existing JAR file, it uses ZipFileSystem instead of the older ZipOutputStream. Unfortunately this has a big drawback:

• JARs generated on systems that only differ by the setting of the default time zone are not identical.

The reason behind this is due to JDK internals:

• The old ZipEntry#setTime/setLastModifiedTime methods use java.util.zip.ZipUtils#javaToExtendedDosTime method, which is independent from the system default time zone,
• The new ZipFileSystem on the other hand uses jdk.nio.zipfs.ZipUtils#javaToDosTime method, which depends on the system default time zone.

Reproduction

To reproduce this problem use any recent project that uses Moditect, e.g. apache/commons-logging and build it using two different time zones.

On my Debian system with JDK 17 I obtain:

piotr@bialykiel:~/workspace/commons-logging$ git checkout rel/commons-logging-1.3.0
...
piotr@bialykiel:~/workspace/commons-logging$ export TZ=Europe/Warsaw
piotr@bialykiel:~/workspace/commons-logging$ mvn clean package
...
piotr@bialykiel:~/workspace/commons-logging$ sha256sum target/commons-logging-1.3.0.jar 
8590cef7d2810aef40334472696e11e3c0c97d6230a3eacaf685e74dc982d5ae  target/commons-logging-1.3.0.jar
piotr@bialykiel:~/workspace/commons-logging$ export TZ=America/Chicago
piotr@bialykiel:~/workspace/commons-logging$ mvn clean package
...
piotr@bialykiel:~/workspace/commons-logging$ sha256sum target/commons-logging-1.3.0.jar 
63ed3b7e92347ffe895d58ab72484af700c132e26206d6a4811d48d9f5c9462d  target/commons-logging-1.3.0.jar

The only difference is in the DOS time stamp of the entries modified by Moditect.

[garydgregory]

TY @ppkarwasz
As a maintainer of Apache Commons, I look forward to a fix and new release!

[hboutemy]

@ppkarwasz I suppose this is an issue that should be fixed by JDK: do you know if it was reported there?

[ppkarwasz]

@hboutemy, it looks like a regression from JDK-7012868, but I always found submitting bugs against the JDK very frustrating (no way to answer JDK dev comments).

Remark that there is another subtle difference between the original JAR entries and those generated by Moditect: the new entries have an extended timestamp extension and looking at the JDK code, there is no workaround for that either.

[hboutemy]

workaround found for equivalent issue in maven-shade-plugin apache/maven-shade-plugin#179

in the case of moditect, it would be nice to disable extra fields (created/accessed/modified time) usage instead of trying to update f3e629b
notice that applying the TZ (like shade) to the update timestamp should do the job also

[aalmiray]

@hboutemy what would be the fix here? MSHADE-420 reads the time from an existing entry. What we need is to write back a given time.

[ppkarwasz]

@aalmiray,

This is a hard one. Unless I am mistaken, as long you use Java's Zip File System:

• the entries of files you modify will either have an NTFS or ExtendedTimestamp extension,
• either way each entry will have a modification timestamp in UTC and a legacy DOS modification time in your local timezone.

Since even in Java 21 the Zip File System does not have any property to change the timezone just for this file system (cf. documentation) and setting the JVM's default timezone in the plugin is not an acceptable solution, IMHO the add-module-info goal must be rewritten to use ZipFile instead. Yes, that is a big patch.

Until then either users must run Maven with an UTC timezone (which is an acceptable option for reproducibility) or they must use the generate-module-info goal.

[aalmiray]

Gotcha. I suppose rewriting to use ZipFile would be the way to go.

[garydgregory]

There is also Conmons Compress.

[aalmiray]

@garydgregory Indeed, but we'd prefer to keep dependencies at a minimum, which means rolling our sleeves and use JSL APIs, even if it means writing more code 😓

[github-actions]

🎉 This issue has been resolved in 1.2.0.Final (Release Notes)