Value type companions, encapsulated

[John Rose]

On 18 Jul 2022, at 18:18, Remi Forax wrote:

> I've just finished to re-read the document.

Thank you!

>
> - There is an issue with Collections.toArray(), this is not well known 
> but toArray(array) add a null isf the array is bigger than the 
> collection size, so if array is an array of C.val i suppose that a 
> default value can be inserted.
> from the javadoc "If this collection fits in the specified array with 
> room to spare (i.e., the array has more elements than this 
> collection), the element in the array immediately following the end of 
> the collection is set to null . (This is useful in determining the 
> length of this collection only if the caller knows that this 
> collection does not contain any null elements.) "

By my reading of that spec, adding `null` cannot materialize 
`C.default`, but rather must cause a NPE, which is the normal result of 
storing a null into a val-array.  (Non-ref arrays never contain `null`!) 
  This will be true regardless of privatization of `C.val`.


> - Do we agree that this document prohibits to create an ArrayList of 
> C.val (or any collections of C.val) if C.val is declared private or 
> package private once the generics are updated (anewarray/aconst_init 
> of C.val will fail at runtime) ?

That depends on translation strategy for updated generics.  If updated 
generics are still erased, then yes.  If we go to the PVM and 
specialized generics, then the TS will surely provide the specialization 
engine with a `Lookup` for the client asking for `ArrayList<C.val>`, and 
can check if that client can really access `C.val`.

Next, if `ArrayList.java` has been recoded appropriately (whatever that 
means, in the end), surely whatever stands for `new T[n]` in the code 
will be able to access the capability of building the array by 
delegating through the specialization anchor (which can hold a `Lookup` 
if the TS sets that up).

Maybe the language will allow a real literal `new T[n]`, or maybe 
`ArrayList.java` has to use some hocus-pocus with method handles.  I 
can’t predict details but I am confident that these issues can be 
handled above the level of the PVM in the bootstrap methods and 
translation strategy.

> This seems too restrictive to me. It should be possible to create an 
> array of T with T a C.val at runtime but it should not be possible to 
> create a C.val out of thin air.

I agree.  One of the challenges of the JLS support for specialized 
generics will be deciding how to permit delegation of the permission to 
do `new C.val[n]` in generic code under the guise `new T[n]` (or some 
equivalent expression), when `T` is `C.val` and `C.val` is privatized.  
It seems clear that some provision should be made.

When I make a specialized generic `Foo<C.val>` or `Foo<C.val>::m` and 
`C.val` is privatized, (a) `C.val` is access-checked to me, but (b) I am 
entrusting its use to the generic as well.  If (b) is not true I should 
be saying `Foo<C>` instead.

…That raises the question, for specialized generics, whether the 
related but distinct access checks on the `C` name should be done (as 
well as for privatized `C.val`).  I guess they should, but this is 
somewhat incompatible with erased generics.  For erased generics, I can 
say `List<MyPrivateClass>` and it all works, because the erased generic 
code can never see `MyPrivateClass`.  If we try that with specialized 
generics, then there are a number of choices:

  - Delegate access to `MyPrivateClass` to the specialized generic (via 
the specialization anchor and a `Lookup` if necessary).

  - Refuse to build the specialization at link-time unless everybody has 
access to `MyPrivateClass`.  (The BSM for the specialization performs an 
access check to `MyPrivateClass` from both the specialized generic code 
and from the `Lookup` of the client.)

  - Build the specialization but throw an error when the specialized 
code tries to do something that would be an access failure in 
written-out code.  (Yuck, late failures!)

  - In the BSM check access to `MyPrivateClass` to the caller, and give 
the specialized code carte blanche to do whatever with it.  (This means 
I can write generics that can “grab” secure capabilities from type 
args.)

  - In the BSM check access to `MyPrivateClass` to both caller and 
generic code (as before) and if either fails, fallback to use erasure.

This is the sort of thing the PVM won’t care about… but the JLS and 
TS (with its BSM support) will have to figure it all out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220720/2ce3a21e/attachment.htm>