java-gnome-developer

RE: [Java-gnome-developer] handlers as ints?

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

> Hello
> 
> Checking the docs I have found that handlers are treated as java ints.
> As we know ints are fixed 32 bits in Java, I wonder what will 
> happen in
> 64bits OSes? As I see it, two solutions are posible: 1. Have a handler
> table to make the conversion, 2. Change everything to long and
> recompile.
> None of this is a good solution.
> I think using a java.awt Peer like solution works better. Hiding the
> handler in an interface that can be implemented in every platform is a
> way to work around this problem without the need to change the library
> in every platform.
> Something like:
> 
> public interface Handler {}
> 
> public class GObject {
>     public GObject(Handler handler) {
>       ...
>     }
>     ...
> }
> 
> In native code, every platform have to implement a pair of functions
> like the following:
> 
> int javaToNative(JObject * handler); // receives a Handler instance
> JObject * nativeToJava(int handler); // returns a Handler instance
> 
> probably inline functions that should be used whenever is necesary to
> access a handler.
> 
> Then you can have a OS32bitHandler with a java int field inside, and a
> OS64bitHandler with a java long field inside, and the code in
> javaToNative and nativeToJava will conditionally use one of those
> implementations depending on the arch.
> 
> What do you think?

It seems like a reasonable solution but will we not
have to change all code that passes the int handle
to use jobject instead?

-Jeff

RE: [Java-gnome-developer] handlers as ints?

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

> Yep, the code have to be changed. :-(
> 
> I have seen also a function to obtain a gtk object from the java
> equivalent, I hope that updating this function makes most of the work.
> If this is not the case or I misunderstand the code, then I suppose
> every component native code need to be updated :-(.
> 
> I think that's the better aproach.
> 
> I volunteer to help on it and send the code changed to anyone 
> available
> to check my work, but first I prefer to check if the developers accept
> the change.

This will be a fairly large undertaking.  Almost all native
methods currently take an integer (the native handle) as the
first parameter.  All of these would have to be changed.  Before
we undertake such a large change I would like to perform a 
little proof-of-concept.  Let's make a change to a couple of
objects and then test on a 32 and 64 bit platform.  Rivas, could
you structure such a test?

This raises a question.  I currently do not have access to a 
64 bit system so testing now and going forward will be difficult.  
How can we gain access to a 64 bit system for testing java-gnome.

-Jeff

RE: [Java-gnome-developer] handlers as ints?

[R. A. R. D. <riv...@ya...>]

--- Jeffrey Morgan <Jef...@Br...> wrote:
> > Yep, the code have to be changed. :-(
> > 
> > I have seen also a function to obtain a gtk object from the java
> > equivalent, I hope that updating this function makes most of the
> work.
> > If this is not the case or I misunderstand the code, then I suppose
> > every component native code need to be updated :-(.
> > 
> > I think that's the better aproach.
> > 
> > I volunteer to help on it and send the code changed to anyone 
> > available
> > to check my work, but first I prefer to check if the developers
> accept
> > the change.
> 
> This will be a fairly large undertaking.  Almost all native
> methods currently take an integer (the native handle) as the
> first parameter.  All of these would have to be changed.  Before
> we undertake such a large change I would like to perform a 
> little proof-of-concept.  Let's make a change to a couple of
> objects and then test on a 32 and 64 bit platform.  Rivas, could
> you structure such a test?
> 
> This raises a question.  I currently do not have access to a 
> 64 bit system so testing now and going forward will be difficult.  
> How can we gain access to a 64 bit system for testing java-gnome.
> 

I can try it, but only on 32 bits. I don't have an 64 bit computer to
test the other part.
It will also help me to familiarize with the library.

rivas.


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: [Java-gnome-developer] handlers as ints?

[Mark H. <mh...@ca...>]

On Mon, Nov 17, 2003 at 01:33:56PM -0500, Jeffrey Morgan wrote:
> This raises a question.  I currently do not have access to a 
> 64 bit system so testing now and going forward will be difficult.  
> How can we gain access to a 64 bit system for testing java-gnome.

Sourceforge compile farm has a couple of 64 bit machines

--
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

RE: [Java-gnome-developer] handlers as ints?

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

> On Mon, Nov 17, 2003 at 01:33:56PM -0500, Jeffrey Morgan wrote:
> > This raises a question.  I currently do not have access to a 
> > 64 bit system so testing now and going forward will be difficult.  
> > How can we gain access to a 64 bit system for testing java-gnome.
> 
> Sourceforge compile farm has a couple of 64 bit machines

I have already posted a question to the support group at
Sourceforge asking is X and the gtk/gnome libraries are
available on the compile farm systems.  I will let you
know once I hear a response.

-Jeff

RE: [Java-gnome-developer] handlers as ints?

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

I just heard back from sourceforge support.  The
stated that X and the gtk/gnome libraries should
be available on most of the compile farm systems.
I have just requested an account on these systems.

> > On Mon, Nov 17, 2003 at 01:33:56PM -0500, Jeffrey Morgan wrote:
> > > This raises a question.  I currently do not have access to a 
> > > 64 bit system so testing now and going forward will be 
> difficult.  
> > > How can we gain access to a 64 bit system for testing java-gnome.
> > 
> > Sourceforge compile farm has a couple of 64 bit machines
> 
> I have already posted a question to the support group at
> Sourceforge asking is X and the gtk/gnome libraries are
> available on the compile farm systems.  I will let you
> know once I hear a response.
> 
> -Jeff
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
_______________________________________________
java-gnome-developer mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

Re: [Java-gnome-developer] handlers as ints?

[Mark H. <mh...@ca...>]

On Mon, Nov 17, 2003 at 10:53:35AM -0500, Jeffrey Morgan wrote:
> > 64bits OSes? As I see it, two solutions are posible: 1. Have a handler
> > table to make the conversion, 2. Change everything to long and
> > recompile.

Since we're using jni, some recompilation will have to be done for each
architecture anyway. Why is it such a bad thing to use longs on 64 bit
architectures and ints on the others?

I would expect your proposal to have unnecessary run-time performance
hits.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [Java-gnome-developer] handlers as ints?

[R. A. R. D. <riv...@ya...>]

--- Mark Howard <mh...@ca...> wrote:
> On Mon, Nov 17, 2003 at 10:53:35AM -0500, Jeffrey Morgan wrote:
> > > 64bits OSes? As I see it, two solutions are posible: 1. Have a
> handler
> > > table to make the conversion, 2. Change everything to long and
> > > recompile.
> 
> Since we're using jni, some recompilation will have to be done for
> each
> architecture anyway. Why is it such a bad thing to use longs on 64
> bit
> architectures and ints on the others?
> 

Advantages
1. Only one code to handle all architectures. Only a tiny piece of C
code have to be conditionally compiled on every platform. The rest is
the same.

2. Java code can't play with handlers, they can just take it, not
operate it, thus avoiding possible bugs.

3. Once the gnome-java package is installed in a platform, the
applications on top of it are truly platform independent, so for final
users is easier to install: they don't need to download the sources and
compile, they only need to download the application and install it, it
will work on any architecture. That's one of the beauties of Java.

corollary: Commercial applications based only on gnome-java and other
java packages will be available on all architectures, not only in x86
as is the usual.

> I would expect your proposal to have unnecessary run-time performance
> hits.

Portability ussually have a cost, in this case one more indirection
when accessing a GTK/GNOME handler (Instead of get int handle field, it
should be get Handle field, then get int/long handle field).
In my case I vote for one more indirection with total arch
independence.

Rivas.


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

RE: [Java-gnome-developer] handlers as ints?

[R. A. R. D. <riv...@ya...>]

--- Jeffrey Morgan <Jef...@Br...> wrote:
> > Hello
> > 
> > Checking the docs I have found that handlers are treated as java
> ints.
> > As we know ints are fixed 32 bits in Java, I wonder what will 
> > happen in
> > 64bits OSes? As I see it, two solutions are posible: 1. Have a
> handler
> > table to make the conversion, 2. Change everything to long and
> > recompile.
> > None of this is a good solution.
> > I think using a java.awt Peer like solution works better. Hiding
> the
> > handler in an interface that can be implemented in every platform
> is a
> > way to work around this problem without the need to change the
> library
> > in every platform.
> > Something like:
> > 
> > public interface Handler {}
> > 
> > public class GObject {
> >     public GObject(Handler handler) {
> >       ...
> >     }
> >     ...
> > }
> > 
> > In native code, every platform have to implement a pair of
> functions
> > like the following:
> > 
> > int javaToNative(JObject * handler); // receives a Handler instance
> > JObject * nativeToJava(int handler); // returns a Handler instance
> > 
> > probably inline functions that should be used whenever is necesary
> to
> > access a handler.
> > 
> > Then you can have a OS32bitHandler with a java int field inside,
> and a
> > OS64bitHandler with a java long field inside, and the code in
> > javaToNative and nativeToJava will conditionally use one of those
> > implementations depending on the arch.
> > 
> > What do you think?
> 
> It seems like a reasonable solution but will we not
> have to change all code that passes the int handle
> to use jobject instead?
> 
> -Jeff
> 
Yep, the code have to be changed. :-(

I have seen also a function to obtain a gtk object from the java
equivalent, I hope that updating this function makes most of the work.
If this is not the case or I misunderstand the code, then I suppose
every component native code need to be updated :-(.

I think that's the better aproach.

I volunteer to help on it and send the code changed to anyone available
to check my work, but first I prefer to check if the developers accept
the change.

rivas.


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree