Re: [java-gnome-hackers] Libraries vs Packaging (1): Linkage
Brought to you by:
afcowie
From: Philipp H. <phi...@gm...> - 2011-06-02 13:05:38
|
Hallo Andrew, > Well, the moment one distro does --enable-something and other distro > does --disable-soemthing in their packages then we have an inconsistent > API for developers. I believe I might have underestimated the impact of a decision like this. Having a library that offers different classes depending on the distro is definitely not a good option. All the more interesting is the idea Francisco suggested. But if you say this is 2yrs work this is not an option for 4.0.x. > My thinking about this has come from the other side. My guess was that > the thing to do would be to put an individual loadNativeLibrary() call > in each package's Plumbing class's static { ... } block, rather than the > single all-encompassing master one down in > org.freedesktop.bindings.Plumbing's. > > That would mean that the only libMODULENAMEjni.so that get loaded would > be those corresponding to modules you actually use as a developer, which > corresponds to the lazy loading of Java classes on the JVM side. Good. I find that so far the best idea, and as far as I see it, it could be implemented with only little changes to the current code and no (?) impact on the current API. Forgive me if I take appindicator as example again, but it's the easiest to imagine for me. How about something like this. As you said, in every optional module Plumbing class, do a static block which loads the library as you said: static { try { loadNativeLib(); available = true; } catch (...) { available = false; } } In the constructor of the class, check if available is true. And if it isn't, throw a ModuleNotAvailableException (extends RuntimeEx..). To avoid try/catch blocks for the developer, you could additionally offer a static moduleAvailable() method to check that beforehand. Applying this to my appindicator example, one could write an application that uses appindicators (if they are available), and statusicons if they are not, something like this: if (Indicator.moduleAvailable()) { Indicator i = new Indicator(...); ... } else { StatusIcon i = new StatusIcon(..); } > It means more .so shared libraries. Lots more. Some people tell me > that's bad. Other people tell me not to worry about it. > [...] > going forward, although that's still very messy for Eclipse. Hm. Don't worry about it :-) By the way, isn't splitting things into modules "separation of concerns". I don't see how that can be bad. Besides, if it's just about Eclipse, you could still create a source directory and symlink the module folders into it (ugglllyy, but hey ...) :-) How much work would it be to externalize a module in a separate .so? Is it feasable to do that for 4.0.x? > P.S. I just checked out your branch, and discovered > ubuntu-appindicator.patch in the root directory. What is that? And then > worse I discovered that you had .so and .jar files added in your > history. Eeek. You don't version control build products and patches :/ I > see that you discovered your mistake, but we're not going to [ever] be > able to merge this branch because it mean bloating everyone's > repositories with this history. Also please fix `bzr whoami` before you > redo these commit(s). > > Please join us in #java-gnome I'm sure someone will be happy to walk you > through using Bazaar. There's a trick with bzr merge and revert that can > compress this all into a single patch which might just be the thing. The ubuntu-appindicator patch is the one Francisco posted in his post a year ago. As you might have guessed, I'm rather new to bzr, so forgive me my kindergarten mistakes :-) Cheers, Philipp |