Per Bothner writes:
> Jeroen Frijters wrote:
>
> > That's why I'm very much in favor of using RawData. ...
> >
> > public abstract class RawData {}
> >
> > public final class RawData32 extends RawData
> > {
> > private int pointer;
> > }
> >
> > public final class RawData64 extends RawData
> > {
> > private long pointer;
> > }
> >
> > All the Java code would ever see are RawData references, but the JNI
> > layer knows that all RawData references are actually 32 or 64 bit (or
> > whatever that platform requires).
>
> But this is a completely different model than the CNI RawData,
> since you're adding an extra layer of indirection.
>
> In CNI, a RawData is not an object that *contains* a pointer;
> the pointer is the RawData reference itself.
>
> I.e.
> inline void* RawData_to_pointer (RawData *rd)
> {
> return (void*) (rd);
> }
>
> *not*
>
> inline void* RawData_to_pointer (RawData *rd)
> {
> return (void*) (rd->pointer);
> }
>
> Adding the extra indirection seems like a bad idea to me.
> I'd rather use jlong.
I take your point. However, if Eclipse used named pointer types
rather than just "int" or "long" I would probably saved about a
month's work. I'd like us not to repeat that mistake.
Okay, we could agree that documentation along the lines of "foo is a
native pointer" would help. But I have a keen bias for self
documenting code where possible.
> But I don't see any real reason not to use RawData. I can see on a
> few JVMs it may cause problems, but they can easily sed the source
> to convert RawData to long. Just think of RawData has a macro.
Or perhaps redefine RawData from its current "raw" form to the form
with an extra layer of indirection -- that wouldn't require the Java
client code to change.
Andrew.
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
