代码拉取完成,页面将自动刷新
# DESIGN GOALS/REQUIREMENTS
o no permanent references to java objects in native code (hard to get rid of)
this means no java object arguments to callbacks; use some sort of integer
key instead (hashcode?) callbacks can hold local data anyway...
o make simplest Java usage map to most common C usage
- additional constructs provided for less-common cases
(WString,Structure.ByValue/ByReference)
o structure is treated as a pointer, except within a struct
o primitive types are passed directly
o arrays are treated as pointers, except within a struct
- in structure (inline; otherwise pointer-to-X should be used)
- as function argument (auto-convert to pointer via Memory)
o pointer to type in struct should use PointerType or Structure.ByReference
o "free" should be invisible wherever possible
# FUTURE DEMOS:
* test keyboard keys' state (needs OSX impl)
* get system process information, basic process control
* additional file utilities (meta info, free space, etc)
* enforce window minimum/maximum size (workaround java bug)
# TODO
* annotations/generics:
o GetPrimitiveArrayCritical: use this if flagged (by annotation? method name?)
o per-arg/return type marshalling
o avoid casts in loadLibrary
o wrap global variables w/type (set/get)
o support annotations of parameters and return values w/o breaking
1.4 compatibility (retroweaver?), e.g.
-- retroweaver (requires retroweaver runtime classes to provide annotation
features) not yet worth doing
void my_function(@MarshalAs(off_t)long arg);
trading off cruft in the interface def to avoid cruft in the usage:
my_function(0) versus my_function(new off_t(0))
this only really applies to NativeLong/IntegerType types that want to use a
primitive value instead of creating an object instance.
o flag string(/wstring)-returning methods which need to free their result
to avoid leaking memory whan auto-creating strings from the result
(since normally we don't take explicit ownership of any returned pointers)
this is a special case for returned strings only, since other returned
pointers are available to the user for later "freeing"
Use a map on library creation, an iface for the library, or annotation
NOTE: how many methods actually do this? strdup...
Maybe make function return "Memory", which can then be converted to a
Structure or some other type. Then memory will free itself when no longer
referenced. (not really common)
* eliminate type conversion contexts; these are almost entirely unused and
more complicated than just wrapping a native mapping in a utility function
* direct non-primitive array arguments (String[], Pointer[], NativeMapped[])
* auto-generate direct mappings/bindings on a per-method basis (perform a
method register on first call to an interface-mapped function) with
sufficient pre-processing to convert to primitives.
* dispose memory/callbacks in Native finalizer to ensure they run first
(use referencequeue to run them when they become unreachable)
* make direct calls call back *once* to Java where conversion is required,
and process all arguments from there (instead of potentially swapping back
and forth multiple times). This also makes it easer to perform conversions
(no native changes required).
* ppc64 direct/raw failures (multiple)
* direct calls on ppc to varargs (callbacks) with FP args fail; avoid them for
now
* Callback.PostCallWrite.write() cf PostCallRead
* universal GCC build w/cross-compile (needs cross compilers...)
* return Pointer.SIZE/LONG_SIZE/WCHAR_SIZE in bits (for consistency with 1.5)
Long.SIZE, Integer.SIZE, et al.
* interface "lvalue", which can provide a pointer to itself (reference() or
addressOf())?
* bitfields for structs (how?)
# DONE
* combine direct and interface mapping calling code where possible
* DOCS: how to properly use W32API_DEFAULT_OPTIONS (A/W, String/WString)
* make native dll extraction from jar public, to use with user dlls packaged
in a jar
* use consistent cpu references (x86->i386, x86_64->amd64)
* osgi for osx
* NO: make Pointer free-able (system allocates memory, client frees it); actually,
this should probably be automatic so the user doesn't have to think about it.
Maybe a custom type representing "function-allocated-pointer" or
"pointer-requiring-free" (which is just Memory). For now, leave it up to
the user to manage the pointer, since they have to define the free method
anyway. use could always put a finalizer on a PointerType-derived type.
- user can do this explicitly if needed
* NO: use libffi java raw? (deprecated)
* NO: MethodArgument/ReturnMapper: per method mapping of arguments/return type.
Can use annotations as shorthand to initialize a map, but basically set up a
per-NativeLibrary (or per-Function?) map of methods to mappers.
Requires separate compilation of annotation handling.
* NO: packaging: 'types', 'convert/marshal' subpackages?
note: marshal/unmarshal vs to/fromnative: to/fromnative is more
explicit, since marshal/unmarshal doesn't indicate src/dst.
o moving conversion contexts to subpackage cleans up top level
substantially, but we probably don't want to move things like Structure and
Pointer into a types subpackage (which would leave just a few top-level
classes). Javadoc is cluttered by example classes anyway.
* cache structure information per-class
* fix setFieldOrder to *always* apply if used
* Make a separate jar file for all OS-specific headers
Maybe make interfaces per-header file (winbase, winnt, stdlib, etc),
aggregated per-library (interface CLibrary extends stdlib, stdio, etc)
(how useful would it really be, or is this just sorting legos?)
o same for windowutils, fileutils, etc. (not useful)
* check Structure "final" fields; should never write back to native memory
* OSX ObjC access (see rococoa)
* do Structure.write for any callback args
* pointer.setValue(), to handle NativeMapped types and move read/writeValue
methods out of Structure, to be used by Function w/NativeMapped[] parameter
* if method has "GetLastErrorException/ErrnoException" in its signature, use
result codes + GetLastError/errno/errstr to auto-generate
runtime exceptions? (cf P/Invoke; also useful for X11 return types)
provide annotation/custom invocation handler/hook to examine return value and
throw an exception if the return value indicates an error
o are error return values consistent (if so, a single handler works)?
if null -> call GetLastError
if nonzero ?
o otherwise, need an ExceptionOnZero, ExceptionOnNonZero runtime, from which
derive GetLastError/ErrnoExceptionOnZero/NZ
* verify get/set methods vs read/write for performance (Pointer)?
(see RawTest for performance comparisons)
* Allow Buffer in Structures (and callbacks) (auto-wrap in direct byte buffer)?
o this gets tricky when reading structs from native memory; we don't know if
the value is already mapped to a buffer (cf CallbackReference)
* standard types for various platforms: posix/types.h, w32 (DWORD, HANDLE)
* embed version in DLL ('depends'-done)/so (symlink?)
* use libffi closure allocation/deallocation
* ensure Library options are passed to NativeFunctionHandler
(needs getLibraryOptions(Class cls))
* handle array of Structure.ByReference as parameter/return value (cf Pointer[])
* test performance of setByte/getByte and pass pointer field directly if it
makes sense to do so (done, halves access time to use pointer field directly,
slight variations on 1.4/1.5/1.6).
* test callback arg/return value for callback type
* structure by value in callback
* call native to fix up FFIType on creation (avoid multithreading problems)
properly handle union by value (or punt; must pass union field instead)
* hash javah-generated headers; when changed, invalidate platform-specific
* add main class which spits out version information
* docs: split pages: FAQ
FAQ: J2ME, new platform builds, stdcall
* struct by reference within structure
* struct by value
(how to do struct value return (vs struct pointer) (uncommon)?)
(how to do struct value argument (vs struct pointer) (uncommon)?)
* use appropriate size_t and off_t sizes (use long offsets everywhere in
Pointer)
* Callback/function pointer as return value (e.g. signal())
* type safety between returned and passed in pointers (w32 API); advantage of
deriving from Pointer is that type mapping can be made automatic, without an
explicit type mapping defined.
* catch native crash/exception/faults and re-throw as java exception
this is mostly for debugging a new mapping to avoid crashing the VM
could do setjmp/longjmp on *nix and catch C++ exception on w32
* NativeMapped: provide interface to automatically convert custom Java
type to/from native types.
* update X11 libs for 64-bit
* use libffi from gcc to handle calls and callbacks?
or move callback asm templates into dispatch_<arch>.c
* more tests for argument types (2 args, all permutations of basic data types)
ensures native stack handling is done properly (handled by libffi)
* universal OSX build w/cross-compile (hard to do with libffi)
* use jna.encoding property to affect string encoding instead of just using
the system default encoding.
* change/augment getWindowHandle0 to provide any heavyweight component window
* unions (copy-on-call is problematic: which member is active?) must require
explicit write, either per member or whole object before export
* rename Argument/Result Converter to be fromNative/toNative
* split unit tests
* auto-convert struct pointers in callback args to Java Structure
(may need a proxy wrapper around callback to avoid excessive JNI)
use proxy for callbacks to enable auto-conversion of arguments and/or return
value (in java-land instead of C-land).
* review/use refactor nativelibrary/function
* auto-generate stdcall decorated symbols (try if undecorated lookup fails)
* per-library jna.library.path: many libraries have a "standard" location (or
several); let the library author indicate what these are (X11, for example)
* return array of struct (annotation to indicate which argument has the
length of the returned value might be nice) (this can now be done with a
type mapper)
* callbacks need a dispose if they are to live beyond the lifetime of the
function to which they are passed; maybe a simpler callback interface for
transient callbacks, and require callback+dispose for most callbacks?
TransientCallback: callback
NonTransientCallback: callback+dispose
(callback is disposed when no longer referenced; user must ensure callback
is not GC'd until it is removed as a native callback)
* auto-convert strings in w32 functions ending in 'W'? would this introduce
any ambiguity?
* Dispose/unload library on GC (use ref queue)
* fix dnd on linux (no hole?) (mostly fixed, still some artifacts)
* transparent/shaped drag image
* windows handles need to be Pointer (void*), not 'int'
* other demos: move to trash, file change notification
* tests for other primitive array types
* build test dll/dispatch lib w/cygwin/gcc instead of msvc (?) under w32
* nested struct alignment (4/8 byte? depends on first element?)
* nested structs in structs: easier to define using struct; use pointer
if you need a pointer
struct auto-converts to pointer as argument, should be inline in struct
(struct should require explicit pointer, argument should require explicit
non-pointer) (maybe use object version of basic type as "pointer" version)
* provide JNA-only search path for libraries
* callbacks
* move javah-generated files to own space
* darwin/PPC asm layer
* enable w32 build with either GCC or MSVC (GCC-built dll doesn't work yet)
* support pointer to basic type argument (int *) w/type safety - what's the
best API from a user perspective? new Pointer(int)? new Pointer<int>?
Base class "pointer to" gets converted to Pointer in invocation handler;
provide a getValue() to retrieve the result; otherwise the memory is opaque
o IntPtr, WCharPtr, CharPtr, ShortPtr, LongPtr, DoublePtr, FloatPtr,
Handle (PtrPtr), getValue(), getPointer()
o add getCharArray() et al. to Pointer?
* inline arrays of primitive types
* remove debug flags (they're not useful)
* Use WString to identify return type and arg
* use interface to identify native, instead of annotation
* isolate stdcall to w32 (should be private to platform)
* generic gcc build/osx(ppc/x86)/linux
* remove generics/enable build under 1.4
* tests for structs
* test float/double
* offset placeholders for structs (explicit alignment)
* vanilla ant build file
* build native stuff from build.xml
* implement basic junit tests
* auto-align struct fields
* handle long/byte/short
* make annotations for native method names optional
// hard clip for now, alpha transparency later
// also allow ImageIcon to be used as clip (getImage())
void setWindowMask(Window w, Shape clip);
// needs:
int findNativeWindow(Window w);
#MAYBE NOT
* should structure offsets be 64-bit? technically yes, but in practice I don't
think a structure that big actually works.
* (maybe) move all native functions into Native (limit header files, easier
management)
* Does it make sense to define Int16/UInt16, Int32/UInt32, etc? Probably not
the signed versions, but maybe the unsigned ones, to facilitate generating
unsigned values (maybe just provide utilities to pack an unsigned int into a
signed int). What about size_t, off_t, et al.? Would either need a
bunch of native lookup functions (more accurate) or java-side conditionals
(less robust but easier to change).
o bounds checking is handled by IntegerType (pass in a long, get an
exception if the value is out of bounds).
o when used as struct fields, could allow detection of field order by order
of initialization (requires all-or-nothing usage, though)
* StringBuffer/StringBuilder as mutable char*/wchar_t* argument
NOTE: byte[]/char[] is probably better; it's trivial to convert to String
and native code can't change the size anyway
* provide library load/unload hooks (Runnables in options?). Examples:
o GetLastError (no longer needed)
o WSAInit?
* determine X11 display name from current java program (if any); null is ok
since it uses getenv(DISPLAY), which is what java would do
note: DISPLAY may be available in GraphicsDevice->getIDstring
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。