commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [net] binary compatibility be damned
Date Mon, 18 Apr 2011 21:28:47 GMT
On 18 April 2011 21:40, Henri Yandell <> wrote:
> On Mon, Apr 18, 2011 at 1:35 PM, Daniel F. Savarese <> wrote:
>> I guess I had more to say, or rather ask.
>> In message <>, sebb writes:
>>>really necessary, because of the additional work that it causes all
>>>downstream users.
>> What additional work?  As far as I know, end users--as in people who don't
>> write code--don't download new versions of Commons Net jars and plug them
>> into the applications that they use.  They don't even know the applications
>> they use depend on Commons Net.  Developers of the applications they use
>> update the jars when they release a new version of their software and
>> deliver it to their users.  Developers are our downstream users and they
>> compile their code before releasing it.  So as long as we remain
>> compile-time compatible, there's no problem.  What am I missing?  That's
>> not a rhetorical question.
>> I must be missing some use case you have in mind, such as something
>> analogous to a Linux distribution updating /usr/lib/ or some
>> other shared library and breaking all dynamically linked user-compiled
>> binaries dependent on it.  The only Java examples of that I can think of
>> are the result of lack of care in deploying applications (where you
>> end up pulling jars into your CLASSPATH that you don't intend).

Exactly - that is the problem.

If you have full control over all the jars and dependencies in your
application, then binary incompatibility is a one-off correction every
time you replace a jar with an incompatible later version.

But if you cannot recompile all the source code, then incompatible
jars can cause your application to break, and you won't be able to fix

> My understanding is that we want to protect people who update without
> doing any testing (or recompiling).

We want to protect against jar hell.

> Personally I agree with you, our stance on binary compatibility is
> entirely too dogmatic and leads to stagnant outdated codebases.

No, it's pragmatic.

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

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

View raw message