Re: Java policy and ABI changes
Quoting Andrew Haley <[EMAIL PROTECTED]>: 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. 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. Hm. All this is a bit extreme. Even the Linux kernel changes its API all the time and things are working okay. Especially with the use of the java classloaders the whole binary compatibility is a bit overrated IMHO. In Maven you can have all sorts of versions of the same jar in parallel and each application can use whichever it needs. I think one way or another it will be necessary to have different versions of various libraries in Debian in parallel. I do not think it will be possible to force all upstreams to always use the latest version (or most secure one or whatever.. how would you select anyway). Just my 2c (and definitely not more..) manfred
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Java policy and ABI changes
Hi, 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 ? Also note that for the moment it is not very widely used, and it has no reverse dependencies. So it may be fine to leave it alone, but I would also like to know what to do if it happens again when it becomes used by eclipse, for example. Cheers, Mike PS: Please Cc: me, I'm not subscribed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
