Re: [java-gnome-hackers] Libraries vs Packaging (1): Linkage
Brought to you by:
afcowie
From: Philipp H. <phi...@gm...> - 2011-06-01 15:58:15
|
Hi again, As you might have seen, I've implemented some changes which I think solve many of the problems you mention below: only the modules you define with the "--with-module=" parameter are compiled in the library. If you leave out a module, the JAR will not contain the Java classes and the *.so will not be compiled with useless stuff. So no UnsatisfiedLinkExceptions. I could even imagine something like "--without-module=(..)" so one could exclude default modules (such as rsvg, or even cairo?!). This is particularly useful if you don't want to use the whole thing, but only very limited parts of java-gnome. I believe that could reduce the filesize (and used memory) drastically. Most importantly: my adjustments do NOT change the default behavior. So the distro versions will not be affected by this. I'd appreciate it if you could take a look at it and tell me whether you might consider including this in the trunk. > 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. It definitely wasn't. That's why we're talking about /optional/ modules, because they are not for everyone. Those who want them can hence simply recompile the library. >> In the long run, I would love a dynamic loader that only allows the >> [..] > > 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. True. That's definitely not how you'd want it. However, I could imagine something like a "hasModule(..)" method for which an application could check in the beginning if all required modules are available. If they are, everything is good. If they aren't, the application exists. That way, the java-gnome library could indeed simply throw an UnsatisfiedLinkException if a non-present module if about to be used. In my opinion, the build time module inclusion/exclusion is much cleaner. > 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. See above. I did address this by simply leaving out both Java and C code for the modules that are not in the --with-module parameter. > 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's true if it is method specific, but it is not if you do it for a whole package (cp. appindicator). > 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. > [..] > 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. That's why I think it should be an optional module. It's in the code, but only for those who want/need it. > [...] > 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]? I think if the *.so and *.jar is compiled with appindicator support, it is not the responsibility of java-gnome to make sure that the native library exists -- it's the responsibility of the application using it. Don't you think? > 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. :-) I hope I'm not the only one commenting on this thread, since I might have a different point of view than others. My main goal is to help the java-gnome library to get more flexible when it comes to optional functionalities. As I intend to include/use only small parts of it in a project of mine, it should be able to reduce the file size of both JAR and SO to a minimum. Cheers, Philipp |