CLinker migration from jdk17 to jdk18

[Maurizio Cimadamore]

On 05/04/2022 18:39, Lev Serebryakov wrote:
> On 05.04.2022 20:30, Maurizio Cimadamore wrote:
>>
>
>> It is very possible to insert return/argument filters on a method 
>> handle only conditionally, which will give you more or less the same 
>> result as what you have in JNI.
>>
>> ```
>> MethodHandle strlen = ... // this will return `int` on LLP64 and 
>> `long` on LP64
>> if (IS_X86) {
>
>  I don't like this condition. Because tomorrow JDK will be ported to 
> some TISC-128 platform, which is LLP64 too, and my code will not be 
> ready for it, as it knows only about "official" platforms. It is what 
> I've tried to say in previous message.
>
>  It will be great, if Foreign API can provide some flags not for exact 
> platforms (x86, Windows, Linux, SysV) but for capabilities: sizes of 
> native types and such.

This was meant as an example (we don't actually provide any flags). 
Regardless of the gating logic being used, if a new platform comes in, 
chances are that you will have to double check your code again (unless 
your code is only calling functions with primitives).

As I said, the Foreign Linker API does not (nor it truly ever had) 
concern with the concept of "portability" - that concept can be added on 
top using combinators (or using tools which do the right thing - e.g. 
use combinators).

That said, I see where you are coming from: having C layouts is not a 
way to make your code magically portable, but querying the size of these 
layouts allow you to make the code more portable - e.g.

```
if (C_LONG.byteSize() == 4) {
    ... // use int
} else {
   ... // use long
}
```

Do I understand the request accurately?

Maurizio

>
>>     strlen = MethodHandles.filterReturnValue(...) // cast return to 
>> `long`
>> }
>> // now strlen always return `long`
>> ```
>
>