Re: draft paper on Java support in Gnome

[Per Bothner <per at bothner dot com>]

Jeff Sturm <jsturm@sigma6.com> writes:

> Padding the Java object with dummy `int' members to accomodate the
> native object seems like an awkward technique.

I agree it is a bit inelegant.

> It will require some sort of pre- or post-processing on the Java classes,

Not sure what you mean.  The int fields are automatically generated - as is
the entire Java class (from a Gtk class description).

> and the classes will no longer be portable.

True, but does it matter?  The generated Java class would be different
on different platforms, but I don't think that is a problem - you have
to re-compile the native methods anyway.

> Also the 32-bit
> alignment of `int' may not be satisfactory on 64-bit machines.

There is no 32-bit alignment.  The int fields are just to give enough
space for the embedded object *and* any needed pre- and post-alignment.
(I just added a sentence to hopefully make this clearer.)

> An alternative is to manually allocate enough memory to store the native
> object immediately following the Java object.  Suppose the Java class
> has a private empty constructor, and (in CNI) we can call the
> undocumented _Jv_AllocObject function directly in place of the `new'
> operator to create a combined instance of gnu.gtk.Button and GtkButton:
> 
>   gnu::gtk::Button *button = _Jv_AllocObject(buttonClass,
>     sizeof(gnu::gtk::Button) + sizeof(GtkButton));
>   GtkButton *peer = (GtkButton *)(button + 1);

That may be better.  But do we need to be able to do
        new gnu.gtk.Button()
in Java code?  (Actualy, I'm not sure.)  If so, we need a hook so the
allocator will also add space for the embedded object.  It just seems
to me that padding with unused int fields is the easiest way to do this.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/