RFR(S): 8240734: ModuleHashes attribute not reproducible between builds
Yangfei (Felix)
felix.yang at huawei.com
Thu Mar 12 09:30:50 UTC 2020
Hi,
> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> Sent: Thursday, March 12, 2020 4:47 PM
> To: Yangfei (Felix) <felix.yang at huawei.com>; core-libs-dev at openjdk.java.net
> Subject: Re: RFR(S): 8240734: ModuleHashes attribute not reproducible
> between builds
>
> The `jmod` and `jar` tools can be used to compute the hashes of a set of
> intimately connected modules. If modules A, B and C are tightly connected, and
> A requires B and C, then you can use the tooling to create a packaged form of A
> that includes the hashes of B and C. The hashes are checked at link-time (and in
According to [1], if A requires B and C, then I suppose the hashes will be included in B and C instead of A when we do 'jmod hash --module-path jmods --hash-modules .*'.
So for the hashed to be stored in A, we may need relations like: B requires A, and C requires A. Am I right?
> the case of modular JARs on the modular path, at run-time too). So I think you'll
> need a new test. It might be that running `jmod --hash-modules` with just two
> dependences is enough to have the entries written to the ModuleHashes
> attribute in random order. A buddy test to JLinkReproducibleTest that creates a
> run-time image containing "user modules" that are tightly connected would be
> a good test.
OK, we will try to add a buddy test accordingly.
Thanks,
Felix
[1]
https://docs.oracle.com/javase/9/tools/jmod.htm#JSWOR-GUID-0A0BDFF6-BE34-461B-86EF-AAC9A555E2AE
More information about the core-libs-dev
mailing list