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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
