> The commit here is a potential fix for the issue noted in > https://bugs.openjdk.java.net/browse/JDK-8258117. > > The change here repurposes an existing internal interface `ModuleInfoEntry` > to keep track of the last modified timestamp of a `module-info.class` > descriptor. > > This commit uses the timestamp of the `module-info.class` on the filesystem > to set the time on the `JarEntry`. There are a couple of cases to consider > here: > > 1. When creating a jar (using `--create`), we use the source > `module-info.class` from the filesystem and then add extended info to it > (attributes like packages, module version etc...). In such cases, this patch > will use the lastmodified timestamp from the filesystem of > `module-info.class` even though we might end up updating/extending/modifying > (for example by adding a module version) its content while storing it as a > `JarEntry`. > > 2. When updating a jar (using `--update`), this patch will use the > lastmodified timestamp of `module-info.class` either from the filesystem or > from the source jar's entry (depending on whether a new `module-info.class` > is being passed to the command). Here too, it's possible that we might end up > changing/modifying/extending the `module-info.class` (for example, changing > the module version to a new version) that gets written into the updated jar > file, but this patch _won't_ use `System.currentTimeMillis()` even in such > cases. > > If we do have to track actual changes that might happen to > `module-info.class` while extending its info (in `extendedInfoBytes()`) and > then decide whether to use current system time as last modified time, then > this will require a bigger change and also a discussion on what kind of > extending of module-info.class content will require a change to the > lastmodifiedtime of that entry.
Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision: - review suggestion - use FileTime instead of Long to prevent any potential NPEs during unboxing - review suggestion - split into multiple statements to make it easily readable - review suggestion - Use Path.of instead of Paths.get in testcase - review suggestion - store e.getValue() and reuse the stored value ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5486/files - new: https://git.openjdk.java.net/jdk/pull/5486/files/945fde6f..8ff75835 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=04-05 Stats: 21 lines in 2 files changed: 3 ins; 1 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/5486.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486 PR: https://git.openjdk.java.net/jdk/pull/5486