James Carman schrieb: > On Thu, Jun 12, 2008 at 8:05 AM, sebb <[EMAIL PROTECTED]> wrote: > > >> Removal of a *public* interface/method/class means that the API is not >> compatible, as it is not possible to replace the jar without breaking >> classes that use these items. >> >> > > I guess I was thinking of the situation where you'd have two versions > of the same jar on the classpath. Obviously the fact that an entire > class/interface is gone would mean that a particular version of a > library isn't backwards compatible. >
The problem is that there is usually a reason why the class or interface was removed. For example, if there once was a FooListener interface available that people could attach to their widgets, and it no longer exists, then it is probably because the rest of the lib is no longer invoking the listener methods on that interface. So simply providing the old interface class will fix *binary* compatibility, but will result in a broken program as the user's objects won't be getting the callbacks it expects. Only cases where the removed classes/interfaces were completely stand-alone and do not interact with the rest of the library does it make sense to provide copies of the old classes. Which won't be the case very often. Oddly, the case of org.apache.commons.lang.enum.* this probably is true. This code just cannot be compiled with java1.5. However the old lang project could provide a new jarfile "lang-enum.jar" that just contains the lang.enum.* classes (compiled with java1.4). This could then be used together with the new java1.5 version of lang to provide full backwards compatibility. In this case, I would say that the lang1.5 version would not need a package-name bump, as (lang15.jar + lang-enum.jar) is a fully compatible replacement for the old version. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
