Just because you can't see it, doesn't mean it's not there.

JEP 371: Hidden Classes in Java

Chris Stewart
© Shutterstuck / Aizuddin Saad

We’ve got our first Java Enhancement Proposal (JEP) of 2020. JEP 371 proposes to introduce “hidden classes”, which should improve how Java works with frameworks. In a future version of the programming language, dynamically created classes could be replaced by hidden classes in places. Let’s take a closer look.

This latest JEP comes from the Project Valhalla team, whose goal is to provide a venue to explore and incubate advanced Java VM and language feature candidates. Their two stated features are Value Objects and Generics over Primitive Types, but they also list “other related topics”, under which hidden classes must fall. So now let’s take a closer look at what this JEP would mean for the programming language.

JEP 371: Hidden Classes

Java developers who work with frameworks know this: Some classes that are dynamically created at runtime are much more visible or long-lived than is actually necessary. This is because the APIs for creating classes, ClassLoader::defineClass and Lookup::defineClass, make no distinction as to whether the bytecode of the class was created dynamically at runtime or statically at compile time. Since the class is defined as “visible” by default, it is used accordingly.

SEE ALSO: Quarkus 1.2 brings support for GraalVM 19.3.1

Good for Java and JavaScript users

The addition of “hidden” classes could cover some use cases that cannot be called by other classes so easily. In JEP 371: Hidden Classes, some such possible use cases are mentioned as examples. For example, java.lang.reflect.Proxy could define hidden classes that act as proxy classes. These would – as the name suggests – implement proxy interfaces. Hidden classes could also be used in conjunction with java.lang.invoke-StringConcatFactory to contain the methods for constant concatenations. When working with JavaScript in Java, a corresponding engine could create hidden classes that contain the byte code translated from JavaScript applications.

Deprecate the sun.misc.Unsafe::defineAnonymousClass API

It is not the the aim of this JEP to otherwise change the Java programming language in any way. Furthermore, it is definitely not the goal of the proposal to support the full functionality of sun.misc.Unsafe::defineAnonymousClass. On the contrary, this could prove fatal for the API: JEP owner Mandy Chung suggests to mark it as “deprecated” and to remove it in a future Java update.

More information about the JEP 371 and details about how the hidden classes work can be found in the JEP description.

Chris Stewart
Chris Stewart is an Online Editor for He studied French at Somerville College, Oxford before moving to Germany in 2011. He speaks too many languages, writes a blog, and dabbles in card tricks.

Inline Feedbacks
View all comments