JDK-8275509: (jlink) SystemModulesPlugin generates a jdk.internal.module.SystemModules$all.class which isn't reproducible

[Alan Bateman]

On 19/10/2021 14:49, Jaikiran Pai wrote:
>
> Ah! So this exact same investigation had already happened a few weeks 
> back then. I haven't subscribed to that list, so missed it. I see in 
> one of those messages this part:
>
> "Off hand I can't think of any issues with the ModuleDescriptor 
> hashCode. It is computed at link time and should be deterministic. If 
> I were to guess then then this may be something to do with the module 
> version recorded at compile-time at that is one of the components that 
> the hash is based on."
>
> To be clear, is the ModuleDescriptor#hashCode() expected to return 
> reproducible (same) hashCode across multiple runs? What currently 
> changes the hashCode() across multiple runs is various components 
> within ModuleDescriptor's hashCode() implementation using the 
> hashCode() of the enums (specifically the various Modifier enums).

The discussion on jigsaw-dev didn't get to the bottom of the issue at 
the time, mostly because it wasn't easy to reproduce.

Now that the issue is clearer then we should fix it. Aside from 
reproducible builds then I expect it is possible to use a 
ModuleDescriptor.Builder to create a ModuleDescriptor that is equal to a 
ModuleDescriptor in boot layer configuration but with a different hashCode.

On the surface, changing the MD hash code to use the ordinal of the 
modifiers should be okay. If the enums values are re-ordered then it 
should also be okay but clearly doing so would end up with a build that 
is not binary identical to a build done with a different order. I think 
we need to think though if there are any implications.

-Alan