Re: Classpath build process and VM-specific issues

[Andrew Haley]

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.