Package de.intarsys.nativec.api

This is the main package of the native c component.

See:
Description

Interface Summary

ICallback
INativeCallback
INativeFunction	The representation of a native function.
INativeHandle	A "handle" to a piece of memory (in c space).
INativeInterface	The abstraction of a generic interface to c native code.
INativeLibrary	A native library (DLL or shared library).

Class Summary

CLong	A plain Java object representing a platform long.
CWideString	Wrapper class to indicate use of a "wide" string on native side.
NativeInterface	Access the VM singleton for INativeInterface.
NativeTools	Tool class for for dealing with the native framework.

Package de.intarsys.nativec.api Description

This is the main package of the native c component.

Here we define the API's and the VM singleton access to native c.

The component itself was built, as we didn't (once again) find anything around that satisfied our needs. We wanted:

• Clean, layered design
• Unrestricted access to all modeled objects and concepts.
• Easy adaption and integration with other views. This means primarily unrestricted access to pointers. There is no use in a native library if i can't bootstrap with a simple address (in our point of view).
• Clean design for c data structures (primitive, composites and references)
• Exchangeable native implementation
• Platform independence

So we created an API and a data structure component and mapped it to JNA, which has great ideas (but in our opinion is to sealed off and has not well done on the data structure side) and can serve as a good foundation. There are some topics we didn't care about yet - this means they may be working or may not, its simply not tested. JNA brings a lot of basic features...

• Pointer size was not really an issue
• We didn't care about byte order

64 bit implementation is under way.