[foreign-memaccess+abi] Integrated: 8308293: A linker should expose the layouts it supports

[Maurizio Cimadamore]

On Thu, 15 Jun 2023 10:27:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is another stab at https://github.com/openjdk/jdk/pull/14037
> 
> I believe, after some offline discussion, that we have found a more satisfying solution to the problem of JAVA_CHAR being exposed. Jorn suggested that linkers should also provide mappings for JNI types such as `jint`, `jshort` and such (which are aliases for our layout constants anyway). I think that's a great way to bring `JAVA_CHAR` back into the fold.
> 
> For now, I decided not to specify support for JNI canonical layouts (but I could do so, if that's preferred). I think the highest priority is to provide some stable mappings for C builtin types (+ `size_t`) as that's what 99% of developers will be struggling with.
> 
> API-wise, we just expose a map. In the preovious PR there were questions as to whether the map should be split into two methods. In general I see the following options:
> 
> 1. Just expose a map (that's the primitive, other things can derived from it)
> 2. Expose a map, plus a method to get a canonical layout from a type name (that's the `Charset` approach, which has both `availableCharsets` *and* `forName`)
> 3. Expose a method to get canonical layout from name, plus a method that returns the set of supported canonical layout names
> 
> My (not so strong) preference would be for either (1) or (2).

This pull request has now been integrated.

Changeset: 7a6fc805
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/panama-foreign/commit/7a6fc8058f721a74433eec9b19d62acc611039d7
Stats:     338 lines in 15 files changed: 289 ins; 34 del; 15 mod

8308293: A linker should expose the layouts it supports

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/panama-foreign/pull/839