JEP draft: Type operator expressions in the JVM? Could happen soon!
A new day, a new potential feature. How do you feel about extending the space of JVM type descriptors to include type operators? If everything goes well, this might soon become reality. Let’s have a look at the draft submitted by John Rose, JVM Architect at Oracle.
There are many new initiatives on the JVM, starting with Amber and Valhalla, two projects that a lot of people are looking forward to seeing in action, Panama, Metropolis, GraalVM, and Loom, to name a few. What’s even more exciting is that changes have to be made in order to accommodate all this growth. Take this new JEP, for example:
John Rose, JVM Architect at Oracle has updated a JEP draft created in mid-June which might make things smoother for Project Valhalla. The idea is to “allow JVM type descriptors (for methods, fields, and constants) to make new distinctions between types not already present in the system of classes, primitives, and arrays. Support future translation strategies which must make distinctions between different usages of the same basic JVM type, or which must provide a way to specify factory input to a class factory or template species factory. Descriptors which can denote complex type instances, such as
List<ComplexDouble> are a necessary component of ‘reified generics’, which in turn are a goal of Project Valhalla. If a value type is to ‘code like a class, work like an int’, then it seems necessary to be able to denote container types which are customized to that value type, rather than being erased to
Object like a reference type.”
JVM type descriptors should include type operators, which are symbolic references to factory-made types. This is a separable component of template classes. Keep in mind that this is not a language feature like lambdas so it won’t propose any specific mechanism for representing parameterized types. Its aim is to offer a necessary “hook” to name such types.
Speaking of what it won’t do:
- won’t provide a new way to define classes. It will only offer a way to associate such classes with a public symbolic descriptor.
- won’t define any language features, nor translation strategies.
- won’t attempt to extend, conflict, or rationalize the current syntax for static generic signatures (JVMS 18.104.22.168).
The idea is to “extend the JVM’s fundamental syntax for field descriptors, once for all future type schemes” -hopefully-, which means that any single type descriptor could be modified by an optional suffix, which constrains the original type descriptor in an ad hoc, programmable manner. As Rose, explained in the draft, “the combination of the original type descriptor and the suffix is called a type operator expression.”
The resolvable semantic elements of this expression are:
- carrier type: the original type descriptor (before the suffix)
- type operator name: a resolved class name and/or simple identifier
- type arguments: one or more type descriptors and/or other constants
It is important to understand that all these semantic elements are optional so they may be omitted.
If the type operator name is omitted, it will be derived from the carrier type, as in the case of a template class whose top type is the unspecialized class itself. If the carrier type is omitted, it is defined to be
Object, the customary carrier for untyped values in the JVM.
You’ll find some potential use cases for type operator expressions in the JEP draft.