Re: Java policy and ABI changes
Mike Hommey writes:
> I have a java library package, called libmozillainterfaces-java,
> that is provided by xulrunner. I'm currently working on a new
> upstream release of xulrunner which changed the java interfaces:
> some interfaces changed namespaces, so you have to do changes to
> your source code, and xpcom initialization is not handled the same
> way (you have to initialize the Mozilla instance before
> initializing xpcom).
>
> Which means classes built with the older version won't build nor run
> as is with the newer version.
>
> What should be done in such case, package-wise ? Change name ? Change
> jar name ? Both ? Other ?
Shoot the maintainers? Well, OK, that would be a little extreme, but
urge the maintainers not to break binary compatibility.
"Despite all of its promise, software reuse in object-oriented
programming has yet to reach its full potential. A major impediment
to reuse is the inability to evolve a compiled class library without
abandoning the support for already compiled applications. . . . [A]n
object-oriented model must be carefully designed so that class-library
transformations that should not break already compiled applications,
indeed, do not break such applications.'
? Ira Forman, Michael Conner, Scott Danforth, and Larry Raper,
Release-to-Release Binary Compatibility in SOM (1995) as quoted in the
JLS.
In my opinion, Java libraries without stable interfaces shouldn't be
deployed in free OSes. If they are to be used, you're going to have
to change the jar name, but even that may not work: if you use such a
library Mozilla, some other version of the same package might be used
by some other Java application running in the same process, and unless
it's firewalled by some ClassLoader trickery it'll break. If that
happens, some trickery like Jar Jar Links may be your only hope.
Andrew.
Reply to: