Pointer/Scope API questions

[Maurizio Cimadamore]

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

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.

>
>
> 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.

>
>
> 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.

Maurizio