"Jochen Hoenicke" <[EMAIL PROTECTED]> writes:
> But when I converted the java.util.zip classes, there were some
> issues that a compiler can't solve:
>
> CNI has the method "elements" to access the elements of an array.
It doesn't have to be an all-or-nothing solution. For something
like Release<Type>ArrayElements, we can require that people put
JNI-specific code in an #ifdef __JNI section. Ideally, we want
to remove the need for that, but it might be good enough to
just *minimize* the need for #ifdef __JNI, at least in the short
term. In other words, in can be an incremental process: Start
out by having G++ munge the header mangling and add __jnienv;
then add support for field access; then method access; then
other features depending on priority.
> Another point is how to put pointers to native structures into a
> classfile. Sun didn't solve it well. If I understand the code in
> japhar's java/util/zip correctly sun used an int field to store the
> pointer and later changed it to long to support 64bit architectures.
> libgcj declares natives fields as "gnu.gcj.RawData", but this is not
> portable to other jvms, where the garbage collector doesn't know that
> this class is special. My solution was to put the structure into a
> java byte array, which imposes a little overhead, but should be
> portable (and you get it freed automatically).
Well, we can still use gnu.gcj.RawData (or gnu.RawData) with JNI.
However, for the JNI case gnu.gcj.RawData would be a real class:
public class RawData
{
int index;
}
Here index is an index into a global RawDataTable
typedef void * RawPointer;
RawPointer** RawDataTable;
#ifdef __JNI
#define JvGetRawData(rdata) RawDataTable[rdata->index]
#define JvAllocRawData(data) new Rawdata(AssignrawdataIndex(data))
#define JvFreeRawData(data) RawDataTable[rdata->index] = NULL
#else
#define JvGetRawData(rdata) ((RawPointer) rdata)
#define JvAllocRawData(data) (data)
#define JvFreeRawData(data) { }
#endif
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
