On 30 November 2012 22:27, Oleg Kalnichevski <[email protected]> wrote: > On Thu, 2012-11-29 at 21:02 +0000, sebb wrote: >> On 28 November 2012 13:47, <[email protected]> wrote: >> > Author: olegk >> > Date: Wed Nov 28 13:47:28 2012 >> > New Revision: 1414683 >> > >> > URL: http://svn.apache.org/viewvc?rev=1414683&view=rev >> > Log: >> > Had to make ClientExecChain and related classes public in order to make >> > them accessible by the caching module >> >> If the classes are not intended to be part of the public API, this >> should at least be indicated in the Javadoc. >> >> Perhaps consider a rename to make it more obvious? >> > > Hi Sebastian > > The new APIs are still far from being final. With the latest changes I > am trying to reduce the public API footprint and ideally I would like to > keep ClientExecChain and related classes package private.
Good plan. > However, I am > not sure it is possible since those APIs need to be accessible by the > caching module and potentially JMX module. We could theoretically > document those APIs as being internal, but then, again, we would end up > in a similar situation as with deprecated code. Would we really want to > change them and risk breaking existing applications that might rely on > them despite the warning in javadocs? If application developers deliberately use classes etc. that are documented as being for internal use only then they need to deal with the consequences. So long as the internal classes etc. are clearly labelled as such, I don't have a problem with breaking strict binary compatibility. > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
