draft paper on Java support in Gnome

Tue Jul 11 06:30:00 GMT 2000

Per Bothner wrote:
> > 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).

I was thinking along the lines of handcrafting the Java delegation
methods, then somehow generating the padding, either before or after the
source is compiled to bytecode (this is normally referred to as pre or
post-processing).
Generating the entire class is an interesting idea... I'm not sure how
easy or effective it will be, based on my very little experience with
gtk. In the general case I think some C-language semantics ought not to
be preserved in a Java API.
> 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.)

OK. I first assumed you would try to align the native object with one
of the `int' members.
> > 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.)

I'd say that would be convenient, but not essential. Some APIs (e.g.
JDBC) are specified mostly by interfaces, in which case the programmer
rarely uses `new' anyway.
Serialization would be complicated by my scheme however...
ObjectInputStream will allocate storage for serializable objects with
private constructors. Yuck.
> 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.

I'm also a little concerned about bloating the class metadata with the
unused fields.
--
Jeff Sturm
jeff.sturm@appnet.com