Short feedback on the linker (CLinker)

[Johannes Kuhn]

So, I played a bit around with the CLinker, to see what is possible and 
what is hard. I used a self-build JDK from the openjdk/jdk repository.

To do this, I picked 3 libraries I had installed on my system:
* JNI
* Tcl
* Win32 api

JNI:
----
This is a bad idea, but someone will inevitably try it, so why shouldn't 
that someone be me.

Entry point is `JNI_GetCreatedJavaVMs`.
Works so far, but the returned handles by JNI are immediately invalid. 
(Somewhat expected, as the native call is over.)
Interesting is that env->FindClass can throw NoClassDefFoundError, which 
I could catch.

What seems to be missing is the ability to use a dynamic address for a 
downcall to support vtables.

Tcl:
----
Works great so far.

Tcl uses something called ClientData (just a typedef for void*) to pass 
application specific structures around. It doesn't try to dereference 
that pointer. The ClientData is only passed to upcalls.

It might be nice to be able to get a "handle" for a java object - 
otherwise you have to implement the bookkeeping yourself.

It would avoid creating new downcall handles just because you changed one

Win32API:
---------

In the past, I often had problems with other FFI and the Win32 api:
Something was clearing the last error, so a downcall to some function, 
directly followed by an other downcall to GetLastError would result in 0.

But with Panama, everything works fine - a call to GetLastError indeed 
returns the error code.

Conclusion:
-----------

Impressive work so far. There are a few areas that could get some 
improvements (vtable support, handles for java objects).

I also noticed that I tend to declare a few classes with final 
MemoryAddress as their sole instance field. I hope Project Valhalla will 
reduce the cost of those type-safe wrappers.

- Johannes