On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd <d...@openjdk.org> wrote:
>> The class generated for lambda proxies is now defined as a hidden class. >> This means that the counter, which was used to ensure a unique class name >> and avoid clashes, is now redundant. In addition to performing redundant >> work, this also impacts build reproducibility for native image generators >> which might already have a strategy to cope with hidden classes but cannot >> cope with indeterminate definition order for lambda proxy classes. >> >> This solves JDK-8292914 by making lambda proxy names always be stable >> without any configuration needed. This would also replace #10024. > > David M. Lloyd has updated the pull request incrementally with two additional > commits since the last revision: > > - Many tests have patterns for lambda class names; update them > - Update comments and javadoc showin the old pattern I took that only as a suggestion; the current implementation achieves the same result by writing the class bytes with *either* the "decorated" name *or* a counter-based name that also indicates that definition has failed. The concern I would have with writing the bytes and then renaming is that the class name would likely conflict with others unless a counter were employed for all dump files from the start; but then, you end up with files disappearing (from the perspective of the user) as well as the counter appearing "out of sequence" after things get renamed to the decorated name. Also IIRC you could potentially get into file lock weirdness on Windows if the user sees & opens the file after it is written but before it is renamed. The only drawback to the current implementation in this patch compared to John's suggestion is that the class bytes will not be written until after the class definition is complete (or fails). But I don't see this as much of a drawback. ------------- PR: https://git.openjdk.org/jdk/pull/12579
