How about using a .internal package? Gary
On Dec 1, 2012, at 16:19, sebb <[email protected]> wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
