Re: [java-gnome-hackers] Libraries vs Packaging (1): Linkage

[Andrew C. <an...@op...>]

On Tue, 2011-05-31 at 22:40 +0200, Philipp Heckel wrote:

> What do you think of that?

I think it's all good.

I've written down some responses below. My only real interest is helping
the project move forward, so please take everything I've written with
that in mind.

++

> However, to avoid getting stuck in an endless discussion about how to
> implement this,

We *do* have to implement $crazy_idea, and hand-waving away engineering
problems isn't really facing up to the challenges involved. In almost
every aspect java-gnome is the way it is because of such limitations. 

Foremost, however, is developer experience: what is it like to use
java-gnome? Thus far we have provided a unified experience to people
using the library; if I write code on Debian you can run it on Gentoo.
I've felt that was important for the last 5 years, but other people can
say what they think.


> many
> developers probably only use a fraction of the built-in functionality.

By the time you're doing anything non-trivial you rapidly find yourself
using the bulk of what's in the library. And that's only going to
increase as GNOME 3 brings increasing convergence between the various
libraries in the stack. The only real exception I'm aware of are those
using it exclusively to do doing drawing with Cairo.

++


>I am referring to the issue of "optional dependencies" discussed in
> [1]: I can definitely understand the discussed problems: 
> Reducing dependencies and having optional dependencies is certainly a
> must in big projects like this.

Well, it is and it isn't. Sure, I raised this topic because it's been on
my mind for a while. And definitely it'd be fantastic to support obscure
corner cases. However, the build-time dependency of java-gnome is "the
GNOME desktop" and the purpose of the library is to allow people to
write applications for the GNOME desktop.

Taking that notion and making it the actual code dependency sure as hell
saved a lot of complication over the years.

As a technical matter, the build system is works by building everything;
if there is a declaration for GtkSomething, Java code and C code are
emitted and that C code will expect to find gtk_somethin_do_whatever()
in headers and at link time. It's (absurdly) monolithic, but as a
practical matter is did mean we got on with it over the past 5 years
instead of wasting time making something that isn't the same for
everyone, and since the build- & run- time requirement is "a GNOME
desktop" I still believe it wasn't actually unreasonable to go this way.

Anyway, that was then, this is now.


> In the long run, I would love a dynamic loader that only allows the
> use of classes for which the native libraries are available. For
> example, if libappindicate is present, an application may use the
> corresponding Java classes. If not, an exception is thrown.

That shouldn't be that hard; I can see a number of ways of doing this
where the result is UnsatisfiedLinkError.

This, however, is not that cool. Consider the current and normal case:
you only get that terminal exception thrown if there's some installation
problem; your app uses java-gnome and java-gnome can either find its
native half or it can't. Very important that it can.

So expecting the library to cope with linking to some things and not
linking to other things is going to get messy. The next matter is pubic
API: do you *really* want to put a try-catch block around every library
call? Surely not. But where else is it going to go? Silently fail? I
don't think so. Uncaught exception? Hardly. So what then? The fact that
I don't have an answer to that is one of the reasons we didn't do this
years ago.

We don't have #ifdef in Java. I personally consider that a feature, not
a bug, but regardless it's not up to me; that's just the way it is and
java-gnome merely conforms accordingly. So enabling or disabling at
configure time as in the C paradigm is only part of the solution, since
we also need to decide what to do on the Java side.

Anyway, I daresay that a uncaught runtime exception is what we're going
to do. I presume UnsupportedOperationException or something custom
parallel to org.gnome.glib.FatalError, maybe
org.gnome.glib.UnsatisfiedFeatureError. whatever. That leaves it up to
the app developer using the bindings to deal with the feature being
present or not? I guess.

++

Another question is API documentation: "this feature will only be
available if java-gnome was built with $X feature enabled" in every
method of the relevant JavaDoc sounds painful - and inelegant.

++


> That way, if the "default version" in the distros' repositories is not
> built with the desired functionality, one could check out the source
> of the current stable version (4.0.19) and simply re-compile it
> --with-module=...

Sure, but I think the real issue is that something like appindicator
that is never going to *be* a part of GNOME and is only available in one
downstream distro is perhaps not entirely suitable for an upstream
library like java-gnome.

Note that this is all same engineering challenge as e.g. WebKit, so the
discussion isn't wasted at all. But first we need to make some design
decisions about what our public API & developer experience is in the
face of optional {upstream,downstream} dependencies.

++

As an aside, but I think a relevant case: I'd observe in passing that I
don't have appindicator packages installed on my Ubuntu system. I'm
running GNOME 3 of course, and have no need of Canonical's Unity stuff.
I would be quite upset if installing Guillaume's java-gnome package
suddenly dragged all those packages in.

For which, of course, there is a standard answer: different packages
depend on different dependencies. Sure. This was actually going to be
the topic of a "(2)" series of emails, but for now consider a few basic
questions:

1. We have the lovely design of only needing the developer to include
one .jar file. That's nice. If we have lots of packages we implicitly
force developers to include zillions of .jar files. That would suck.

2. What about Gentoo? Unlike Debian, they doesn't build multiple binary
packages for a single source package. They do have a wonderful build
time optional dependency mechanism though.

++

If the code is present in the library but not to be built, how [this is
an implementation issue but a huge one: like I said, right now all the
code builds - the list of .java and .c files to be built is simply the
result of `find`. There's no manually articulated list of classes. There
could be. It's been nice not to have all the bugs that happen because
some manual file list is wrong. Perennial nightmare in other projects]

++

> However, in my opinion, an issue like
> this should not stand in the way of making progress and including new
> functionalities:

I agree.

> Francisco implemented support for App Indicators over
> a year ago [2] and even though is works like a charm, it is still not
> in the library.

So we have some design and engineering issues to consider. What do you
want to happen if you're on any Linux other than Ubuntu-with-Unity and
there are no app indicators?

Should the class not exist [which would mean conditionally including or
not including code in the .jar file. Very hard]?

Should the C code not be emitted [which would mean a call down that code
path would hit the native declarations and would result in
UnsatifiedLinkError]?


++

Whew!

I'm sitting outside at a cafe in the early morning shivvering my ass
off. :) so I think I'll just send this now.

To reiterate what I said at the beginning, I am really happy to be
having this discussion. I think you'll agree that the implications are
non-trivial. And as long as people are thinking about that, and keeping
in mind the experience for

        developers [our audience],

and not forgetting

        hackers [the people who have to a) do the work now, b) package
        the resultant mess and c) & d) maintain it in the future],

and finally most important of all

        users [make sure that applications written against java-gnome
        provide a good experience for the users of those applications]

then I'm sure that we'll do the right thing.

If people decide that any or all of these concerns are not important,
then that's fine by me.

AfC
Sydney