Reproducibility for Java -> technical details

[Vagrant Cascadian]

On 2024-11-12, John Gilmore wrote:
> Roland Clobus <rclobus at rclobus.nl> wrote:
>> My proposed change would be:
>> * At startup of Java, check if SOURCE_DATE_EPOCH is set. If so, create
>> a Clock.fixed with the timestamp from SOURCE_DATE_EPOCH
>> * In java.util.Date replace System.currentTimeMillis() with
>> Clock.getInstance().currentTimeMillis() (as suggested at [4] and other
>> sources)
>
> The clock functions in Java shouldn't stop working because somebody set
> a common environment variable.  This is hitting a fly with a
> sledgehammer.

We've been hitting those flies with this particular mechanism for nearly
a decade now and it is largely working as intended:

  https://reproducible-builds.org/docs/source-date-epoch/

SOURCE_DATE_EPOCH is not pretty or ideal, but it sure is pragmatic. I
would rather people not embed timestamps, there are no timestamps like
no timestamps! Moving forward sometimes requires making imperfect
compromises...


>> It should be noted that regular user _will not_ and _should not_ set
>> SOURCE_DATE_EPOCH [6]. That environment variable it typically used for
>> rebuilds.
>
> Certainly many programmers will set the variable, particularly during
> development or debugging sessions.  And they will and should expect the
> ordinary programs that they run in that shell to keep working -- whether
> they are written in Java or not.

What about C? It has been the default behavior in GCC and CLANG for
years. Numerous other programming environments as well.

The vast majority of reproducible builds fixes are from various
toolchains respecting SOURCE_DATE_EPOCH.

It is out there. It is widely supported. It does the job, however ugly.


> A much less intrusive fix would be to provide a date option on
> ca-certificates-java that would override the current date with
> a date specified on the command line.

Having to patch each and every package to specify a bespoke build flag
is really not feasible for tens of thousands (millions?) of packages...
that sounds pretty intrusive to me.

Would I rather there be no timestamps embedded anywhere? Definitely!

Do I want to rehash that argument with each and every upstream project
in a conversation re-explaining the reasons why? Definitely not!


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20241112/cd7498ef/attachment.sig>