RE: [Java-gnome-developer] Use of destroy()

[Jeffrey M. <Jef...@Br...>]

I am working on 64 bit support now.  Please see my earlier
posting to see how I proposed to solve this problem.

-Jeff



> -----Original Message-----
> From: jav...@li...
> [mailto:jav...@li...]On Behalf Of
> Robert Marcano
> Sent: Saturday, October 30, 2004 1:25 PM
> To: jav...@li...
> Subject: Re: [Java-gnome-developer] Use of destroy()
> 
> 
> On Sat, 2004-10-30 at 13:06, Jerry Haltom wrote:
> > It does. The "problem" as I see it though is Java does not 
> allow you to
> > store pointers natively: period. It's stored as an 'int' 
> now, which is
> > guarenteed signed 32 bit on ALL PLATFORMS. There is discussion on
> > changing it to a long, which is signed 64 bit ON ALL 
> PLATFORMS. There is
> > no "native pointer". It would be nice though! THere is talk 
> on putting
> > it in a long I think, or a class. I think they both suck 
> though. With a
> > long you can't fit it all in a register, with a class you have to
> > derefrence (vtable lookup).
> > 
> 
> Another solution can be define both fields (int and long) and let the
> native code decide which one to use. But will the performance increase
> enough to allow the extra memory usage?
>  
> ________________________________________
> Robert Marcano
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 

 NOTE: THIS IS A CONFIDENTIAL COMMUNICATION. This transmission is intended
only for the use of the individuals or entity to which it is addressed. If
you are not the intended recipient, or the person responsible for delivering
the message to the intended recipient, please return or delete it
immediately. Although this e-mail and any attachments are believed to be
free of any virus or other defect, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by us for
any loss or damage arising in any way from its unauthorized modification or
use.