Re: Java support in GTK/Gnome

[Per Bothner <per bothner com>]

Tim Janik <timj@gtk.org> writes:

> your email carried a From: Tim Janik line for me, eventhough it should
> probably have originated from per@bothner.com?

Oops.  Sorry.  I cut the "From" line from Oskar's forwarding, and I guess
I forgot to change the From itself.

> yeah, i had miguel mentioning that idea to me earlier, but on second
> thought, it's just bothering about a few additional bytes per object<->proxy
> connection, while at the same time enforcing it makes proxy overhead mandatory
> for every GObject, even those that Java doesn't really have to/want to deal with.

Well, my main argument for embedding isn't space, since I think it is
likely to be close to a net wash either way.  The main advantages of
embedding are (I think) that it is conceptually simpler (no proxy
objects), and faster (trivial mapping from Java<->C worlds).

> you've got extra API function overhead for every class that introduces a
> signal of which tehre are quite a bunch. and for every one of them, you'll
> at least need variants for add*Listener, remove*Listener, block*Listener and
> unblock*Listener.

Well, I think that is desirable.  I'm assuming that the Java classes are
generated more-or-less mechanically from the Gtk definitions.

> while you can certainly do that, and prolly the one good reason here is type
> safety, you will have to still work on a generic interface for dynamically
> added signals (much more so once GType interfaces can introduce signals), so
> i personally would rather focus on making that generic part as convenient
> and flexible as possible.

I think if the "generic interface" as equivalent to Java reflection.
It has its uses, especially when dealing with unknown classes, but
in normaly use reflection should be avoided:  It is slower, and defers
type-checking to run-time.  Most of the time, I imagine Java programmers
would use the typed add*Listener, remove*Listener Java-style methods.

> yeah, but to gain 4 or 8 "wasted" bytes per proxy used by the actuall
> java program,

More than that.  Each proxy needs a pointer to the Gtk object, each
Gtk object needs a pointer back to the proxy, plus there is the overhead
of two objects versus one.  Still, it's not very much, I agree.

> to make a quick estimate, i roughly guess you end up with at least two
> extra uneeded proxies per widget in an application.

Huh?  If we use embedding.

> furtherly considering that- especially for composite widgets -not all of
> the widgets are going to be directly adressed by java functions, it's
> pretty evident to me that your embedding idea creates a huge bunch of
> overhead even for intimidating complex apps that shuffle around a lot
> with widget sytem internals.

It is not clear to me at all.  It depends on how may small objets there
are (for large objects the overhead doesn't matter) that are not
accessed by Java code.

> you might want to talk to some of the other language binders we have
> around, afaik all of them use on-demand-proxy creation.

That is certainly an argument for the proxy approach:  Consistency
and compatibility.  Somehow I doubt very many of them any strong
arguments or evidence either way as to efficiency, though.

> the time costs, i'd guess, will be pretty insignificant.
> for java->gobject it'll be a pure pointer field readout of
> your implementation structures, and for gobject->proxy lookups,
> you can use object_set/get_data indexed by quarks (similar to XAtoms,
> GQuarks are global integer ids assigned to strings) which will in
> 2.0 boil down to a binary search through all the object data items
> installed on that gobject (i.e. O(log2(n_data_items))).

So lets say at least 10 instructions (including some memory accesses)
to do the search instead of one subtraction (with no memory accesses)
to do the reverse mapping.  That is quite significant.  (Of course
that does not mean it is significant in the big picture.)

> if you use dynamic proxies, you may even destroy those once java
> references go away, release you gobject reference with that and
> let the gobject live on, maintained by glib/gtk then. if it's later
> rereferenced like say through contain.get_children(), you could
> recreate the proxy. i'd think you can be way more memory efficient
> with this approach.

I wouldn't be surprised if you're right.  However, I think the
embedding approach would be way more *time* efficient.

> > I agree this is a concern that argues for the proxy approach.  However,
> > the embedded approach does not preclude language mixing, as long as
> > at most one language at a time needs to do embedding.  It may also be
> > possible to use a hybrid approach, combining embedding and proxies,
> > for the rare cases where that is needed.
> 
> hum, how'd you decide then which objects to force-create proxies
> for then and which not? and how will language bindings figure
> which one is in charge of doing extra object padding and which not?
> to me, this sounds like an enourmous complexity imcrement at doubtfull
> benefit.

I agree you probably don't want to do that.  I.e. you don't want to
use two languages bindings in the same application where both use
embedding, unless both languages share an object representation.
One plausible answer:  Use a shared object run-time, like Microsoft
is doing with .Net.  I think that may be the most elegant answer
long-term, but it assumes we agree on a "common object run-time"
model, like Microsoft seems to be doing.  Language implementation
that don't use the common run-time model can still use proxies,
of course.

A shared common run-time is not yet appropriate for Gnome, but I think
we should keep an eye on what Microsoft is doing with .Net and C#.

Do note that Gcj is a step in the direction of a shared run-time:
It uses basically the same object model for Java and (single-inheritance)
C++.  That is the point of CNI - to make it easy to access Java objects
from C++ and vice versa.

> for one i think with the above i outlined why i don't believe that
> the cost to the gtk core would be minor.

I meant the cost to the gtk core is one extra global "hook" variable,
pluss checking that before object allocation.  That is trivial.

The cost *when using Java* may be more, of course.

> for another it's not at all clear to me in what apps you'd be
> more efficient with your aproach.

The only applcations where embedding is *not* more efficient is
if there are lots of small objects that are not accessed as Java
objects.

> other than for your embedding idea, why would i want such kind of
> allocation hook anyway?

Instrumentation, debugging, automatically generating proxies.

Let me emphasize: I'm not doing any of this work, Oskar is.  I think
the embedding approach is more elegant and easier to understand.  I
think embedding wins on time efficiency; it may lose on space
efficiency, but that is less clear; another potential disadvantage is
that it is different from how other language bindings do it, and it
works best in a "common run-time" world, which we don't have yet.

However, I could be happy with either implementation model, as long
as the Java api is clean (offers full access to Gtk/Gnome, hides the
difference from the Gtk object model, reasonably efficient, can be
used to build awt/swing widgets with).  It would be nice if both
choices were available, assuming if they presented the same api to
the Java programmer.  (I think comparing the two approaches might
make a useful research paper.)

What I'm really unhappy with is the current state, where there is no
usable Java binding to Gnome.  I suppose Sun will change that, given
their recent OpenOffice.org and Gnome Foundation announcements,
but that may not help us if we want to use a Free Java implementation.

> hm interesting, a scheme binding mapping back to java byte-code.
> hadn't heared of that yet. on a more personal note, i'm toying with
> support for multiple language backends for one of my applications,
> scheme and ruby should definitely be an option, while java would
> be nice as well. but i guess there's no ruby->java byte-code
> project underway yet, is there? ;)

Well, Kawa is meant to support multiple languages.  There is almost
usable implementation of Emacs Lisp (see http://www.JEmacs.net/), as
well as some support EcmaScript (JavaScript) and Common Lisp support.
I don't know anything about Ruby, so I don't know how difficult it
would be to add a Ruby front-end for Kawa.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/