On Sun, 17 Apr 2022 16:17:30 GMT, liach <d...@openjdk.java.net> 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.
>
> A summary of the rest of the changes:
> 1. Merged the two passes of determining module and package of the proxy into
> one. This reduced a lot of code and allowed anchor class (for hidden class
> creation) selection be done together as well.
> 2. Exposed internal API for obtaining a full-privileged lookup to the rest of
> `java.base`. This API is intended for implementation of legacy (pre
> `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more
> complex tricks to obtain proper permissions as lookups.
> 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959):
> passes methods computed by proxy generator as class data to the hidden proxy
> class to reduce generated proxy class size and improve performance.
>
> In addition, since this change is somewhat large, should we keep the old
> proxy generator as well and have it toggled through a command-line flag (like
> the old v49 proxy generator or the old reflection implementation)?
>
> Please feel free to comment or review. This change definitely requires a CSR,
> but I have yet to determine what specifications should be changed.
It's good to see more experiment and prototype for this issue. Like Alan
said, the spec change, compatibility risks and security issues in particular on
the serialization spec/impl change require lot of discussions and also
prototyping of other alternatives. A new API may also be one alternative to
consider.
The current spec of Proxy class is defined with null protection domain (same
protection domain as the bootstrap class loader). Lookup::defineHiddenClass
defines the hidden class in the same protection domain as the defining class
loader. This would become a non-issue when the security manager is removed.
However, before the removal of security manager, we still need to look into the
compatibility risks and what and how applications/libraries depend on this
behavior.
During the development of JEP 371, I had a prototype of converting dynamic
proxies to hidden class by adding a shim class (that's what your prototype
does). That raises the question "how to get a Lookup on a package for the
dynamic proxy class to be injected in without injecting a shim class (i.e. your
anchor class)?" This functionality could be considered as a separate RFE.
However, frameworks don't always have the access to inject a class in a package
defined to a class loader. This is something worth looking into.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8278
