draft paper on Java support in Gnome

Mon Jul 10 21:24:00 GMT 2000

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/