days
-1
0
hours
-1
-1
minutes
-5
-4
seconds
-2
-2
search
It's just a draft though

JEP draft: Type operator expressions in the JVM? Could happen soon!

Gabriela Motroc
JVM
© Shutterstock / alexkich

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, PanamaMetropolis, 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<int> orList<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.”

tl;dr

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 4.7.9.1).

SEE ALSO: Java 10: What do Java developers want? Projects Amber and Valhalla! When do they want them? When they’re ready!

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.

asap

 

Author
Gabriela Motroc
Gabriela Motroc is editor of JAXenter.com and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of