RFR: 8292914: Drop the counter from lambda class names

[Brian Goetz]

On Wed, 15 Feb 2023 20:46:47 GMT, David M. Lloyd <duke at 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.
>
> (On the debugability topic) I had thought to change the lambda class dumping code so that it would dump the class bytes *after* the class was defined (to capture the unique hidden class name completely). But this would exclude the case where the class would fail to be defined, which would probably undermine some significant percentage of the cases where you'd want a dump in the first place. Maybe in this case, since the class name would never appear in any stack trace anyway (and thus there is nothing to actually correlate), it could be dumped with a separate counter like `..Lambda$$-error1.class` or something?

@dmlloyd Exactly so.  The dumping is most useful in debugging cases where there are weird issues with access control or verification, or bugs in LMF that might cause errors on load.  I remember before we put the counter in, being bitten by "the first dumped $Lambda$blarg class file was overwrittten by the second, and I couldn't find the bug because it was in the first one, but I didn't realize there were two."  So the counter actually did pay its way at least once.  

That said, I do think the filename conflict was the main reason we needed it, and there are other ways to disambiguate file names.  In fact, it might be even better if we constructed the file name as "$timestamp-$classname$", so that (a) they would sort and you could find the most recent ones easily, and (b) dumps from later runs would not clobber dumps from previous runs.  I think that would also solve @mlchung 's concerns?

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

PR: https://git.openjdk.org/jdk/pull/12579