Credit: Dreamstime
A proposal before the OpenJDK development team would add hidden classes to Java, a capability intended to improve the efficiency of language implementations built on the JVM.
Hidden classes are classes that cannot be used directly by the bytecode of other classes, according to the JDK Enhancement Proposal. Rather, hidden classes are intended to be used by frameworks that generate classes at runtime and use them indirectly via reflection.
A hidden class can be defined as a member of an access control nest and may be weakly referenced by its class loader. There is no timetable yet for when hidden classes might appear in Java.
In explaining the motivation behind the plan, the proposal states that many language implementations built on the JVM leverage dynamic class generation for efficiency and flexibility.
Java’s javac compiler, for example, does not translate a lambda expression into a dedicated class file at compile time but emits bytecode to dynamically generate and instantiate a class. Similarly, non-Java JVM languages often implement higher-order features by using dynamic proxies to generate classes dynamically.
The implementers of these languages usually want a dynamically generated class to be part of an existing statically generated class and to have properties desirable of dynamically generated classes such as non-discoverability and access control. However, the standard APIs that define a class weren’t designed with these purposes in mind.
If the standard APIs could define hidden, non-discoverable classes with a limited lifecycle, then frameworks inside and outside of the JDK that generate classes dynamically could define hidden classes instead, improving JVM language efficiency.
Goals of the hidden classes proposal include:
- Enabling frameworks to define classes as non-discoverable implementation details of the framework, so they cannot be linked against by other classes, or discovered via reflection
- Deprecation of the non-standard API,
misc.Unsafe::defineAnonymousClass, with the goal of removing it in a future release - Not changing the Java language at all
- Support extending an access-control nest with non-discoverable classes
- Supporting aggressive unloading of non-discoverable classes, giving frameworks the flexibility to define as needed
