[foreign] road to posix

[John Rose]

On Jun 1, 2018, at 10:40 AM, Florian Weimer <fweimer at redhat.com> wrote:
> 
> please come to libc-alpha and ask us to provide something that is digested more easily

That sounds good.  FTR, Panama is not just about C headers.
It is about building a framework in which any data+function schema
of APIs can be efficiently plugged into the JVM.  So it's not just C or
C++ but protocol specs and persistent memory structures and on-disk
formats and stuff not invented yet.  We've been relentless about designing
the framework down to essential functionality (memory access and
procedure calls), not just our (second-)favorite language or compiler.

The important deliverable of Panama is therefore not Posix bindings,
but rather a language-neutral memory layout-and-access mechanism,
plus a language-neutral (initially ABI-compliant) subroutine invocation
mechanism.  The jextract tool grovels over ANSI C (soon C++) schemas
and translates to the layouts and function calls, bound helpfully to
Java APIs with unsurprising names.  But the jextract tool is just the
first plugin of many.

We do look forward to building more plugins for more metadata formats
outside the Java ecosystem, such as what you are building.

In fact, I expect that, in the long run, we will not build all of the
plugins, but that people who invent new data schemas (or even
data+function schemas or languages) will consider using our
tools (layouts, binder, metadata annotations) to integrate with
Java, instead of the standard technique, which is to write a
set of Java native functions from scratch, or (if you are very
clever) with tooling.  The binder pattern, in particular, seems
to be a great way to spin repetitive code for accessing data
structures of all sorts, not just C or Java.  I hope it will be used,
eventually, in preference to static protocol compilers.  The
JVM is very good at on-line optimization, even of freshly
spun code, so it is a natural framework for building a binder.

(Also, since the binder hides its operations behind interfaces,
it is also possible to engineer ahead-of-time versions of the
binder, to use at AOT time or when a JAR is required.  Thus,
the binder can subsume the old static generation techniques
for protocol stubs.)

All that said, we have to do the first couple of plugins ourselves,
just to shake out the backend (layout, binder, etc.) and make
it more likely to succeed with third-party efforts.

Thanks for inviting us into the libc-alpha conversation!  I look
forward to someday parsing whatever modern metadata C
invents to manage its modules, whether that is booted through
an old-C DLL of stubs, or via a binder plugin which can directly
read the modules.

— John