Toolcache extracted with wrong modification timestamps

Description:
setup-java action for Zulu JDK garbles timestamps of the installed files. This may cause issues in up-to-date and dependency checking, if an application depends directly or indirectly on JDK library classes, e.g. tool APIs. It is often assumed that dependencies (in this case jars or jmods from the JDK) must be older than compiled code linked to those dependencies in order to consider that compiled code up-to-date.

Task version:
v3

Platform:

• Ubuntu 20.4.5

Runner type:

• Hosted

Repro steps:
Investigated here: https://github.com/apache/netbeans/pull/4921 ; according to the logs, the extracted JDK contents bears the time-of-installation timesamp:

2022-11-15T11:50:59.9471865Z -rw-r--r--+ 1 runner docker 18348414 Nov 15 11:50 tools.jar

This is the action invocation, with the ls logged immediately after.

Expected behavior:
Installed JDK files should retain timestamps as they are stored in the installation archive.

Actual behavior:
Installed JDK files get all modification stamp from the time JDK was installed on the builder machine.

Start with the setup-java action's toolcache extraction path and compare the archive timestamps with the installed files reported in the Apache NetBeans PR #4921 logs. Review the action invocation in .github/workflows/main.yml at line 153 and reproduce the extraction on Ubuntu. Done means installed JDK files retain the modification timestamps stored in the installation archive.