Pointer/Scope API questions

[Ty Young]

On 1/7/20 10:07 AM, Maurizio Cimadamore wrote:
>
> On 07/01/2020 15:47, Ty Young wrote:
>> So has the goal of Project Panama completely changed then? IIRC, 
>> first it was about just providing native code access, then it was 
>> discovered that the use case of better/safer memory access could be 
>> supported and was in-line with the project's goals, and now the 
>> original goal of providing native code access seems to be the 
>> afterthought as apposed to memory access. This has turned into a bit 
>> of a roller coaster(although that seems to be theme of Java projects 
>> in general).
>
> I understand the frustration - but this was really announced as part 
> of the minimal jextract story:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/jextract_distilled.html


I didn't read it fully. Apologies.


>
> Note that it's not much as the Panama story has changed, as much as it 
> is about the fact that we realized which pieces really belong in the 
> JDK (memory access var handle, native method handles) vs. which pieces 
> do not (e.g. Pointer, Struct, Callback, ...).
>
> With the lower-level primitives provided (method handles, var handles, 
> MemoryAddress and MemorySegment) all the abstractions previously 
> offered by Panama as part of the JDK can be easily built ,if needed, 
> _on top of it_.
>
> After having played with lower level bindings for some time, I 
> honestly didn't find myself missing the Panama API much - and if more 
> abstractions are needed they can always be built (even by clients!) on 
> top when and if the need arise.


My concern(as i've said earlier on this list IIRC) with this is the 
duplication of effort and fragmentation. You're going to potentially 
ending up with 20 Pointer interfaces(vs one interface, many 
implementations) and they are going to name clash with each other all 
the time. Heck, someone could make a version of the same bindings but 
choose to do something completely different for no good reason just 
because they can. Now you have potentially multiple projects that depend 
on two different bindings for the same thing that are potentially made 
in different ways.


Point is, while I understand as an API maker the desire to only provide 
the absolute minimum, this decision could blow up badly down the line 
when it gets into people's hands.


>
>>
>>
>> What's the status of the jextract API side? I imagine not much has 
>> changed because of the holidays but I'd like to get off Pointer if 
>> the entire API is going to be abandoned ASAP.
>
> I've just pushed the initial implementation of the jextract API in the 
> foreign-jextract branch.
>
> We will start working on pushing an initial implementation for the 
> minimal extraction tool.


If you're sure this is the route you're going towards i'd be happy to 
take it for a spin if it's in a semi-usable state. Do you plan on doing 
a basic run down of how to use it?


>
>>
>>
>> I don't feel like Pointer should be abandoned though. Pointer is an 
>> interface, not an implementation.... If there are platform specific 
>> details that need to be worked out then that's an implementation 
>> issue. jextract can(and actively does) have the ability to dump 
>> working binding code that can be modified as desired. Could jextract 
>> not simply have the ability to generate very generic bindings for 
>> those that just want native access quickly(or don't care about 
>> cross-platform or whatever else) or as a base to work off of to 
>> provide higher quality bindings? 
>
> As I said, a jextract tool will be provided, only it will not do 
> exactly what it does today, and the methods it will generate will be 
> slightly lower level. Exactly how much lower level, is still TBD - we 
> are at a very early stage, but with more experience working with 
> minimal bindings, my hope is that we will soon converge to an 
> idiomatic form that is both usable and, yet, primitive enough to be 
> extensible.


For my use case(example: [1]) currently I'm not even using jextract 
bindings raw but instead creating a wrapper to convert the C function 
bindings to an object oriented API. Based on prior discussion on 
accessing functions not specified in a header, its sounding like the use 
of jextract can be/is null and void in part or completely if you can 
just define everything yourself. By the end of this, what benefits is 
jextract even providing exactly?


[1] 
https://github.com/BlueGoliath/GoliathEnviousNative/blob/master/modules/org.goliath.envious.nvml/src/main/java/org/goliath/envious/nvml/local/attributes/utilization/NVMLGPUGraphicsUtilizationAttribute.java


>
> Maurizio
>
>