On Sat, 5 Sep 2026 16:25:37 GMT, Alan Bateman <[email protected]> wrote:
>>> The head branch is benshuai5D:codex/JDK-8250677. Can you say if any part of >>> the changes in this PR were generated by codex? >> >> No. AI was used only to help understand the surrounding code, identify >> relevant existing tests, and organize test results. >> The code changes in this PR were written and reviewed manually by me and my >> colleagues. > >> I was used only to help understand the surrounding code, identify relevant >> existing tests, and organize test results. The code changes in this PR were >> written and reviewed manually by me and my colleagues. > > Thanks for confirming. > > I'm not sure yet about doing anything about this. The proposed change looks > like it will break the contract for Object.hashCode in that two equals > Version objects might have different hash codes, e.g. "1" and "1+0". > @AlanBateman > > > I'm not sure yet about doing anything about this. The proposed change looks > > like it will break the contract for Object.hashCode in that two equals > > Version objects might have different hash codes, e.g. "1" and "1+0". > > That’s already broken in the current version for `"1‑a"` and `"1‑a+0"`: Thanks for pointing this out. The existing equals/hashCode issue is tracked by [JDK-8362427](https://bugs.openjdk.org/browse/JDK-8362427) and is currently in progress. This change would expose another instance with "1" and "1+0". Should this PR wait for JDK-8362427, or can the parsing fix proceed independently? ------------- PR Comment: https://git.openjdk.org/jdk/pull/32715#issuecomment-5556763249
