Re: Classpath build process and VM-specific issues

[Steven Augart]

Andrew Haley wrote:
> Strong typing for legibility and reliability is IMO for more
> important.

I strongly agree with this, on software engineering grounds.

> And here it is with named opaque types:
>
> public static final synchronized native int
> g_signal_handlers_unblock_matched(gpointer instance,
>                                   int mask,
>                                   int signal_id,
>                                   int detail,
>                                   GClosurePointer closure,
>                                   gpointer func,
>                                   gpointer data);

These are great examples from SWT.

If we were to do this in the GNU Classpath Java code, then the only 
solution I see is to use a preprocessor, and expand gpointer to an int 
or long as appropriate, based upon the standard pointer representation 
in that platform's usual ABI.

I have no idea what we will do when 128-bit machines become available. 
  Probably by that time Sun will have added a type called "long long" 
or "long128", and we'll expand "gpointer" to that on the 128-bit machines.

Like Andrew, I am uncomfortable with using byte[] to represent a raw 
pointer.  I also see Etienne's point of view that a class to 
encapsulate the data is pretty heavy-weight, and that only a few VMs 
would implement special handling for the RawPointer type.  Worse, a VM 
that did handle it specially would not binary-compatible with one that 
treated it as just another class.  Ick; there are no good solutions.

I hate to introduce the notion of a preprocessor.  Oh well, I guess I 
just did.
--
Steven Augart

Jikes RVM, a free, open source, Virtual Machine:
http://oss.software.ibm.com/jikesrvm