commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [net] binary compatibility be damned
Date Mon, 18 Apr 2011 20:40:13 GMT
Daniel F. Savarese wrote:

> 
> I guess I had more to say, or rather ask.
> 
> In message <BANLkTikf9iGKczWraRDW_yb50wuD9x4+GQ@mail.gmail.com>, 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.

An application that depends on two components that themselves require two 
(binary incompatible) commons net versions. 

> I must be missing some use case you have in mind, such as something
> analogous to a Linux distribution updating /usr/lib/libstdc++.so 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).

You can no longer care in the situation above, it simply does not work.

- Jörg


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


Mime
View raw message