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.
