RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v9]

[Sean Coffey]

On Mon, 23 Oct 2023 09:14:06 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update code comments

Thanks for the test code suggestion Jai. I expanded test case coverage during development of the fix. While your suggested test case captures the core issue at hand, I think it misses a few important points that I captured in the current test. 

* ZipFile behaviour in the scenario where a file is re-opened and edited while references to the old ZipFile exist. A "invalid LOC header" needs to be thrown in cases where an old zip file mapping is still in use. An old iteration of this patch was going to remove use of lastModifiedTime and probably would have caused issue for some apps. This test case protects us in the future from that.

* the behaviour of incorrectly adding extra <Key, Source> mappings to our internal map has gone undetected for a few years. We've no test coverage in that area. The current test closely monitors numbers in that map now and allows for behavioural differences between Filesystems that support and don't support fileKey(). I think that protects us from future changes we might make in this area also.

I think your test will fail on windows. The rel and abs file Keys are still treated as different there (proposal to use getCanonicalPath seems too costly for performance)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1774912190