On Tue, 21 Feb 2023 18:39:31 GMT, Volker Simonis <simo...@openjdk.org> wrote:
>> Volker Simonis has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Remove assertions which insist on Lambda proxy classes being strongly >> linked to their class loader >> - Removed unused import of STRONG und updated copyright year > > I hear your arguments although I don't agree :) > > Can we at least get consensus on that the current design to create a new > ClassLoaderData for each non-strongly linked Hidden Class just in order to > enable simple unloading isn't the greatest design and should eventually be > replaced by a more sophisticated implementation which allows non-strongly > linked Hidden Classes to share a single ClassLoaderData but still enable > unloading for them once they aren't referenced any more? @simonis I want to ask a basic question -- what is the reason for your code to call `LambdaMetafactory.metafactory()` directly? It looks like you want to implement so sort of dynamic dispatch. Can equivalent functionality be implemented by the app itself? If there's a real need for such a style of programming, and it requires some sort of built-in support in by the JDK, maybe we should have a proper API instead of piggy-backing on `LambdaMetafactory.metafactory()`. I think if you give us more background, we can make this a more productive discussion than focusing on "did we make the right decision N versions ago" without defining what "right" means :-) I would suggest re-booting this decision in the mailing lists rather than continuing in this PR. ------------- PR: https://git.openjdk.org/jdk/pull/12493
