Re: [java-gnome-hackers] Libraries vs Packaging (1): Linkage
Brought to you by:
afcowie
From: Andrew C. <an...@op...> - 2011-06-01 01:19:12
|
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 |