JDK-8242888 : Convert dynamic proxy to hidden classes
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-04-15
  • Updated: 2024-07-10
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.
JDK 24
24Unresolved
Related Reports
Blocks :  
CSR :  
Relates :  
Description
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.
Comments
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