RFR: JDK-8242888: Convert dynamic proxy to hidden classes

[Alan Bateman]

On 17/04/2022 17:24, liach wrote:
> Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building.
>
> The main compatibility changes and their rationales are:
> 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior.
>     - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes.
>     - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain.
>     - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe.
> 2. The disappearance of proxies in stack traces.
>     - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic.

It's great that you have time to experiment in this area but just to set 
expectations that it will likely require significant discussion and 
maybe prototyping of alternatives. It suspect the Reviewer effort will 
end up being many times the effort required to do the actual work 
because of the compatibility and security issues that will need to be 
worked through.

I think you need to add non-discoverability to the list of compatibility 
issues. Do we know for sure that there aren't frameworks and libraries 
that use Class.forName on proxy classes? We've had issues in the past 
with changes in this area.

It's too early to say but it might be that the compatibility risks may 
nudge this one into creating a new API.

-Alan.