On passing --date to jrt-fs jar at build time

[Magnus Ihse Bursie]

On 2025-03-28 11:28, Galder Zamarreno wrote:

>
>
> On Fri, Mar 28, 2025 at 11:00 AM Severin Gehwolf <sgehwolf at redhat.com> 
> wrote:
>
>     On Fri, 2025-03-28 at 10:25 +0100, Galder Zamarreno wrote:
>     > Hi,
>     >
>     > I continue experimenting with building mainline on Nix and I've made
>     > some progress. Capstone, Ant and others are in, but I had to work
>     > around an issue when trying to run JMH benchmarks [1].
>     >
>     > Seems like when `test` make target is run, `jrt-fs` jar file is
>     > created passing in `--date ...`. In Nix, I was getting this error:
>     >
>     > ```
>     >
>     /nix/store/5y040sypyg0amh0igxs9rnx5fmj0d88i-temurin-bin-23.0.2/bin/jar
>     --create --date 1980-01-01T00:00:00Z --file
>     /Users/galder/1/jdk-avoid-cmov-long-min-max/build/release-darwin-arm64/support/modules_libs/java.base/jrt-fs.jar
>     --manifest
>     /Users/galder/1/jdk-avoid-cmov-long-min-max/build/release-darwin-arm64/support/modules_libs/java.base/_the.jrt-fs.jar_manifest
>
>     > ...
>     > date 1980-01-01T00:00:00Z is not within the valid range
>     1980-01-01T00:00:02Z to 2099-12-31T23:59:59Z
>     > ```
>     >
>     > @Andrew Leonard found the root of this validation in [2]. It seems
>     > unlikely this is going to change.
>     >
>     > The cause is that on Nix shell envs `$SOURCE_DATE_EPOCH` is set
>     > to 315532800 which is 1980-01-01T00:00:00Z. This can be easily
>     worked
>     > around by unsetting SOURCE_DATE_EPOCH and that works fine for my use
>     > case.
>     >
>     > However, @Thomas Fitzsimmons had a very good point to make:
>     >
>     > >  I also wonder why the test harness is passing --date
>     > > $SOURCE_DATE_EPOCH, since the test jars are not distributed, not
>     > > sure why they'd need to be reproducible...
>     >
>     > I think his question is valid. Why pass --date for a test jar?
>
>     I might be missing something, but isn't the question about why pass
>
>     --date $SOURCE_DATE_EPOCH
>
>     ... when creating jrt-fs.jar? jrt-fs.jar isn't a test jar. It's
>     the JDK
>     8 compatible FS provider for JDK 9+ to read the JRT files.
>
>     Are you suggesting it's only happening when running "make test"? I'd
>     assume the same would happen for 'make images' too after JDK-8288396.
>
>
> Before trying to run `make test` I was just simply calling `make` and 
> that didn't cause the jar to be created.

That will just call the default target, which is "jdk" unless you have 
set something different with configure. That is a convenience target for 
developers to get most, but not all, of the stuff built that is needed 
to check that you did not break the build and to be able to run a fair 
share of the tests.

You need to call "make jdk-image" to get a complete image that can be 
distributed.

I was going to point you to the relevant part of the build readme, but I 
noticed that this is not clearly spelled out there. I guess we should 
update the documentation to make this clear.


>
>     Couldn't you just set SOURCE_DATE_EPOCH to a value after 1980-01-
>     01T00:00:02Z (btw, that looks like a bug to me; valid range should
>     really be T00:00:00Z).
>
>
> Yes that would also work, same as unsetting SOURCE_DATE_EPOCH. About 
> the range, see the PR comment in [2]


You can use the "--with-source-date" configure option. With it, you can 
either pass in a ISO-8601 date string, or some of the convenience 
aliases. I'd recommend using "configure --with-source-date=version"; 
this will pick up the official release date of the JDK version you are 
building and using that to set SOURCE_DATE_EPOCH properly for all tools 
executed in the build.

/Magnus



>
>     Thanks,
>     Severin
>
>     > [1]
>     https://github.com/NixOS/nixpkgs/issues/387516#issuecomment-2760642591
>     > [2] https://github.com/openjdk/jdk/pull/6481#issuecomment-982399628
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250402/b21703e1/attachment-0001.htm>