JDK-8242888 : Convert dynamic proxy to hidden classes
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Priority: P4
  • Status: In Progress
  • Resolution: Unresolved
  • Submitted: 2020-04-15
  • Updated: 2024-10-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8315810 - Reimplement sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles
Blocks :  
JDK-8341999 - Allow unloading of dynamic Proxy implementation classes
CSR :  
JDK-8332770 - Convert dynamic proxy to hidden classes
Relates :  
JDK-8229959 - Convert proxy class to use constant dynamic
Sub Tasks
JDK-8340955 :  
Release Note: Experimental Hidden-Class-based Proxy Implementation - Open
Description
Dynamic proxy is serializable and supported by the default serialization. On the other hand, hidden classes cannot use default serialization since it does not have a binary name. Instead it has to use a custom serialization mechanism. The serialization story will need to be sorted out.

Proxy is specified to be created with same protection domain as the system classes loaded by the bootstrap class loader such that this permission check will pass through this frame. Hidden class is defined with the same protection domain as the lookup class. This is a spec change and also needs to look into the permissions required.

In addition, Lookup::defineHiddenClass requires a Lookup object of the same package. Dynamic proxy may inject a proxy class in an empty package. This may need a way to obtain a Lookup for a non-existing package for an unnamed module but a Lookup for an existing package for a named module. This can be workaround to inject a shim class in an empty package that use its Lookup to inject hidden proxy classes.
Comments
Restore the description of this issue to the original version. Move the version updated by [~liach] as a comment: As hidden classes, the methods can be passed as an immutable list class data, accessed via a condy, so the implementations can use `List.get` to access the Method objects, without using reflection to initialize fields. The Proxy implementation is therefore simplified. Dynamic proxy is serializable and supported by the default serialization. In JDK-8315810, default serialization now support hidden classes, now that it allocates instances with MethodHandle (backed by Unsafe). The serialization specification and implementation thus need no update. Proxy implementations appear in stacktraces, and they cannot be hidden in the existing implementation due to it being under user ClassLoaders; meanwhile, hidden class methods are always hidden. This change in stacktrace will affect users; we can add a flag to restore the old implementation, so that users can ensure their code works properly on both implementations to ease transition.
21-10-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/19356 Date: 2024-05-23 03:28:30 +0000
09-07-2024
The PR mentioned the possibility of changing the serialization specification. This is not to be undertaken lightly, as serialization is generally required to be forwards and backwards compatible across JDK releases. This may pose insurmountable compatibility issues in reimplementing proxies using hidden classes. An alternative was mentioned of introducing a new Proxy API. If this is done I recommend revisiting the feature of making proxies serializable. When Proxies were introduced in JDK 1.3, the idea was that "everything" be serializable. (Also, serializable proxies were used in RMI dynamic stub creation in Java SE 5.0, and those stubs could be transmitted over RMI, which inherently uses serialization.) We should reconsider whether new Proxy instances should be serializable.
22-04-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/8278 Date: 2022-04-17 16:17:30 +0000
17-04-2022
DasBrain, so I've prepared another patch that moves proxies over to hidden classes + class data for obtaining method instances at https://github.com/openjdk/jdk/compare/master...liachmodded:feature/hidden-proxy?expand=1 based on the plan outlined at https://bugs.openjdk.java.net/browse/JDK-8229959?focusedCommentId=14489248&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14489248 This patch appears to pass the primitive jdk java/lang/reflect/Proxy and a few other previous tests that failed due to security manager restrictions on my end. I also simplified proxy logic so that it bakes the module and package information in one pass than two. Imo this is the best we can do to retrofit an antique model to the new access control system under lookups. If there is a proper lookup provided (e.g. in the same package as package-private interfaces), we can avoid all these hacks for obtaining a proper lookup. And I believe we should look into creating a new proxy API sooner or later (though technically third-party libraries are empowered enough for this with the modern Java API)
17-04-2022
I know that this is a bigger project. Currently, it has some unsolved dependencies - one of my goals is to reduce it's usage on it's privileged position inside java.base. One possibility is to allow frameworks to get a "ClassDefiner" (name subject to bikeshedding) for an unspecified, unused package in a class loader and define classes there. The ClassDefiner would encapsultate the package, ClassLoader and ProtectionDomain. But the ClassLoader is also part of the ProtectionDomain. Maybe JDK-8201574 can help exploring that topic. Then there is the dependency on JDK-6824466. Without that, serialization for proxies (and annotations...) would break. And then I would like to get rid of the shim class. In short - this is nowhere near any satisfactory solution. But at some point, it might be. (And at that point, it might not need to be sponsored.)
08-02-2021
[~jkuhn] This RFE is not a small project by itself. It has implications to Java SE specification and also security. FYI. This would not be a good candidate for sponsoring.
08-02-2021