commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [net] binary compatibility be damned
Date Wed, 20 Apr 2011 17:26:22 GMT
Many applications rely on a single class-loader.

Not all applications can easily be changed to use multiple
classloaders,  and anyway I don't think Commons should force end-users
to use multiple class-loaders to fix compatibility issues.

Since a single class loader can only load a single instance of a given
class, this implies that Commons releases must be binary compatible.
If the release is not binary compatible, the new release must use a
different class/package name to allow the old and new classes to
co-exist in the same classloader.

This approach solves the loader problem for applications that may
indirectly depend on more than one version of a single jar.

Changing a class/package name is pretty cheap for the developer of a
component; generally this can be automated by the IDE or a script.

However the total downstream cost is potentially much greater, as
every user who wishes to use the new version needs to update their
code and recompile. For a popular component such as Lang, this may
mean changing a very large number of other codebases.

The cost of maintaining binary compatibility needs to be weighed
against the cost to downstream users.

Yes, sophisticated users can employ tactics such as OSGI, shading, or
multiple class-loaders to get round the classloader issue, but I do
not believe that Commons components should force this on end-users.

Commons components are intended to be widelty reusable; to ensure that
this is true we need to take care that the APIs are stable and
releases are compatible.
When we do need to break with the existing API, it needs to be done
carefully (and infrequently) so as to minimise the effect on
downstream users.

I'm not saying that binary compat overrides all other considerations,
but I think we need to consider the cost to downstream users very
carefully before embarking on changes that affect them all.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message