Calling SLUL code from JVM
==========================

(and similar environments, such as CLR and maybe Python, Perl, etc)

Alternative 1
-------------

- Bundle SLUL interface file as a resource
- Provide a set of classes that match the SLUL interface:
    - A single interface for all "global" and typescoped functions
    - One class per struct type
    - One enum per enum type
      (other types?)
- A "SlulLoader" class that:
    1. parses the SLUL inteface file, and computes and verifies SHA256 of
       the api_defs (as well as other syntax/semantic checks?)
    2. loads the SLUL library, and checks that it has the desired
       APIs with matching SHA256.
       This means that native code needs to be loaded into the process.
    3. constructs proxy classes that call into the native code.
- This requires a binfmt that includes the SHA256 sums.
  (This *could* be ELF, with some kind of special symbols and/or
   special section)

If the loaded binary can be assumed to be generated by a correct SLUL
compiler (and not tampered with), then the result is memory safe:
- the SLUL inteface and the binary interface of the native is verified
  to match (due to the SHA256 check).
- the proxy classes match the SLUL interface.

Problems/limitations:
- uint/wuint types
- structs with embedded arrays
- nested arrays become ugly (must be one-dimensional in Java)
- refs to int, etc.
- SLUL's struct packing