Future of primitive specialization (generics) and null-restriction

[Remi Forax]

----- Original Message -----
> From: "-" <liangchenblue at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Monday, May 22, 2023 5:43:15 PM
> Subject: Future of primitive specialization (generics) and null-restriction

> Hello,
> Since we have null-restricted types now, I have a few questions about
> its implications on existing primitives and expanded generics:
> 
> 1. Are Integer.TYPE (int.class) primitives etc. now the same as the
> null-restricted type of Integer etc. value-type wrappers?

Conceptually, they are not the same, Integer! is a subtype of Object while int is not.
We want to try to unified them but it won't be easy :)

> 2. Will type parameterization like List<int> be written like
> List<Integer!> (null-restricted specialization), effectively
> invalidating JEP 218, as the same performance can now be achieved with
> value-type parameterization in VM without invasively changing the type
> hierarchy assumptions of generics? (JEP 8261529 doesn't appear updated
> to the current null-restriction model)

It's still in flux.

List<int> is a kind of reification of List<Integer!> where the parametrized class also have bridges to convert from Integer! to int.
So a simple first approach is to only allow List<int> when you inherit/implement a class/interface.

i.e.
  class IntStream implements Stream<int> { ... }  // Ok
  List<int> list;  // Ok
  var list = new ArrayList<int>();  // Not ok
  var list2 = new ArrayList<int>() {};  // Ok
  var list3 = (List<int>) ...  // Not ok, no way to check if bridges are present at runtime
  var list4 = (List<Integer!>) ... // unchecked cast but Ok
  
 
It means that int is a subtype of Integer! when overriding.
We can not go in the other direction due to a limitation of how the bridges work in case of separate compilations.

And we also need some VM magic so Integer![] is seens as an int[] at runtime, when "new T[size]" is specialized with T=int, so at least, iaload/iastore + checkcast needs to work on an Integer![].
int[] and Integer![] are different classes, but it's the same layout in memory.

> 
> Curious,
> Chen Liang

regards,
Rémi