Re: [java-gnome-hackers] Libraries vs Packaging (1): Linkage
Brought to you by:
afcowie
From: Francisco O. <fr...@pu...> - 2011-06-01 17:19:38
|
Hi all, First of all, thanks Philipp to bring this back, I really love to see the indicator patch in trunk too. Not only for the particular functionality but to reopen the discussion about the optional dependencies. Putting the topic about including non-pure-gnome dependencies aside, Let me give you my point of view (see comments below) > 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 really like the compile-time flags proposal ...but not include the java classes in the JAR is BIG problem from (library) users perspective. You will end up with a non consistent API from java side, you will have version java-gnome 4.0.20 with the library or without it and the user will not know it. Or based on the distro will have it or not. Same java program will throw a ClassNotFoundException in the platform not supporting the functionality. > > 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. > I was thinking about this for more than a year too. Here are 3 options: - leave it to the user: hasModule() solution Philipp suggested and throw the runtime exception if its invoked anyway (hey, users call) - check on every method call: if dependency is not satisfied continue silently. The problem with this is if the response trigger some condition, and that will depend on the library :( - using a factory: its a derivative of the previous one, but cleaner. The factory is responsible of provide the correct implementation, it will return a class that implements an interface which can be the real implementation or the mocked/not supported by the system one. Again , its more code but 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? I agree the user should check it...or use the mocked version. The problem with the later is big libraries (appindicator is small) will create more code. > > > 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 > Thanks, Fran |