BUG: SystemABI C_LONG and C_LONGLONG are the same

[Ty Young]

On 5/20/20 8:41 AM, Maurizio Cimadamore wrote:
>
> On 19/05/2020 15:05, Ty Young wrote:
>> I don't think hiding low level Panama details is the way to go about 
>> things, and I hope that if Panama does add a higher level API, it 
>> doesn't go the route of trying to directly model C code like 
>> "Pointer" kinda sorta did.
>>
>>
>> I'd personally like to see something like I did, but I'm both biased 
>> and realize it's probably unrealistic. The amount of classes that 
>> this otherwise thin abstraction layer is a bit much for the JDK. In 
>> my defense, the type specific values and arrays only exist because 
>> Java doesn't support primitive generics.
>>
>>
>> It would be interesting to get a wider perspective on which approach 
>> is better. Do people think a smaller higher-level API is better which 
>> has more "god-like" objects or is a more thinly spread, targeted, and 
>> lots of classes better? I largely stand by the way I went about it, 
>> but I'm still personally interested in what others prefer and think. 
>
> This is a very good and constructive point. What kind of high-level 
> API would people expect?
>
> By having spent time looking at what other languages did in this area 
> (e.g. Kotlin, Swift and the likes), and, by also looking at what more 
> traditional Java bindings for native libraries do (e.g. LWJGL) - at 
> some point they all seem to reach out for some kind of pointer-like 
> abstraction. So I think that _not_ having some kind of higher-level 
> Pointer abstraction in the long run could be counter-productive.


Happy to read this. FMA before the recent changes was already a bit of a 
"assemble it yourself" type of API and it has already gotten more so 
with recent changes.


>
> The problem you raise about lack of support for primitives (and, more 
> generally, looking forward to Valhalla) inline classes inside generics 
> (although we have plans for those) remains, IMHO, one of the main 
> blockers to provide one such abstraction. My personal opinion is that 
> the old pointer API was not too bad, but it failed because it doesn't 
> go the full way towards supporting the full spectrum of C types.


You mean C primitive types, right? If so, I feel like the lack of a 
abstraction of Struct/Unions was an issue as well.


A way to put an overarching structure on a function like I have with 
"NativeFunction" will probably be desirable too. While it wasn't an 
issue with the old Pointer API because jextract cleanly generated 
everything for you, now that you need to deal with the function's 
address, MethodHandle, and FunctionDescriptor... well, shoving 
everything into one class probably isn't going to be pretty for any 
decently sized library.


I got to thinking about other things that would be useful as part of an 
abstraction as well: library modeling and versioning.


It would not be, I think, unexpected for someone making bindings for 
something like, for example, OpenGL to want to create minimum binding 
sets for older hardware. The good news is that Java has rich polymorphic 
features that can allow this... the bad news is that a lot of this is so 
library specific I don't know how much could be done to help here. You 
can't just say that version "2.0" of some library is just version "1.0" 
+ some new functions because functions may have been removed or do 
different things in version "2.0".


> As a side-effect, bindings written this way will also be more portable 
> too - since abstractions such as `c_unsigned_long` and the likes can 
> be coded in a way so that they take into account platform differences. 
> Which means the signatures of your methods do not change across 
> platforms.


I wonder, is this really a good idea, even as part of a higher-level 
abstraction? A long clearly has different sizes on different platforms 
and attempting to artificially smooth those differences over at an 
abstraction layer level seems like its pushing the abstraction part a 
bit too far to the point of misleading.


Anyway, I don't know when the final discussion on when "What kind of 
abstraction will FMA have?" will take place, but I would hope it won't 
be too late when FMA is already part of the JDK. It is inevitable, I 
think, that a higher level abstraction may put some spotlight on some 
minor issues with FMA that may not be fixable if at that point.