commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: [lang] Java 5
Date Thu, 12 Jun 2008 12:29:59 GMT
James Carman schrieb:
> On Thu, Jun 12, 2008 at 8:05 AM, sebb <> 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

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message