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
