Reproducible jar archives.

[Ricardo Wurmus]

Hi Guix,

Java libraries are usually installed as jar archives.  These are
(optionally compressed) archives containing the “.class” files;
optionally, they may also contain a manifest.

These archives are created by the “jar” tool, which is part of the JDK;
they can also be created by “fastjar”, an alternative implementation in
C.

Unlike “tar” the “jar” tool does not support anything like the “--mtime”
flag, so file modification dates cannot be reset before packing.  Also,
the manifest is usually generated automatically (unless manually
provided) and the generated directories and the manifest file itself
have uncontrollable timestamps.

Although compiling “.java” to “.class” with the javac compiler is
deterministic, packaging up the “.class” files to a “.jar” is not for
the above reasons.

For Java projects without a build system this is not so bad: we can
generate our own build.xml and build the project with Ant.  The
build.xml would just have to run a command to reset the modification
time of all files before archiving them.  (This is what my WIP
‘ant-build-system’ does and packages built with it are, in fact,
deterministic.)

For many non-trivial projects, however, we have no way to easily inject
a phase before “jar” is called, because of some indirection through
build plugins (in the case of Maven projects) or because of a convoluted
build.xml for Ant, which may use different Ant tasks to package the
“.jar”.  I only came up with two ways to get around this problem:

* build the “.jar” archive as usual, then unpack it, reset all file
  timestamps, and archive them again (this time without generating an
  additional manifest)

* patch up the “jar” tool so that it resets the mtime for archive
  contents.

The first approach might work if we can reliably find a point in the
build process where all “jar” archives have been created (after the
“build” phase?).  It’s an ugly solution because we have to do so much
more work for every “jar” (unpacking, touching, and repacking can take a
lot of time and space for big projects).

The second approach is tempting.  I looked at the “fastjar” code and
making it set the file modification time is trivial; of course this must
be optional (e.g. when a certain environment variable is set) lest this
affects operation under normal conditions.  But it’s also really hacky.

I haven’t looked at the sources for the JDK-provided “jar” tool yet, so
I cannot say if that would work.

What do you think about this?  Other ideas maybe?

~~ Ricardo