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

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

On Thu, 2011-06-02 at 15:05 +0200, Philipp Heckel wrote:
> 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,

Careful; Plumbing classes [and their subclasses] never get instantiated.
We'd have to manually put in a check somewhere (everywhere?) else.
That's doable, but error prone. :(

In fact, only place we've done it is in Cairo. [And one of these days
I'm going to move the checkStatus() calls down to generated C code.
Better stack traces.]

>  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.

Yeah, that would be sensible, wouldn't it.

We tend to have a "static class" [sic, my own term] that goes with each
package. org.gnome.glib.Glib, org.gnome.gtk.Gtk, etc. So we could put
moduleAvailable() [or maybe isAvailable()?] there on each of those.

        [Java behaves a bit funny about static methods with the same
        name appearing in subclasses. It doesn't do inheritance quite
        the way that I though, I suspect because the compiler generates
        an invoke static with a given class name, not invoke virtual].


I'd almost be more tempted to suggest that public isModuleAvailable()
work by invoking the code path that leads to the loadNativeLibrary()
call.  After that, if you have the temerity to call something its either
there like it should be or your app is broken like it should be.

Hm.


> By the way, isn't splitting things into modules "separation of
> concerns". I don't see how that can be bad.

It's bloody horrible when someone wants to use your libappindicator-java
only to discover they've got to install 4 other modules.

Java's lack of a dependency system in its shared libraries (which is a
different but parallel problem during development and at deployment
runtime) is horrible here. Hence the one source project (developers) and
[at the moment] one resultant .jar [& .so] (deployment).

Anyway.

>  Besides, if it's just
> about Eclipse, you could still create a source directory and symlink
> the module folders into it (ugglllyy, but hey ...) :-)

Horrid and manual experience for developers. Java is already hard
enough. Eclipse for newbies is insane. Costs us people all the time.
They show up in #java-gnome wanting to "try it" because "they've heard
Eclipse is cool" and an hour later are lost for good.

> As you might have guessed, I'm rather new to bzr, so forgive me my
> kindergarten mistakes :-)

Not at all. Takes time to learn the ins and outs of anything you haven't
worked with before.

AfC
Sydney