Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Flume >> mail # dev >> [DISCUSS] Annotating interface scope/stability in Flume


Copy link to this message
-
Re: [DISCUSS] Annotating interface scope/stability in Flume
I'm also in favour of that idea.

Jarcec

On Tue, Aug 14, 2012 at 11:40:17AM +0100, Brock Noland wrote:
> Hi,
>
> I think this makes sense. Can we clearly state and define a contract for
> Public and Internal?
>
> Brock
>
> On Tue, Aug 14, 2012 at 10:38 AM, Mike Percy <[EMAIL PROTECTED]> wrote:
>
> > It seems we have reached a point in some of the Flume components where we
> > want to add features but that means adding new interfaces to maintain
> > backwards compatibility. While this is natural, the more we do it, and the
> > more we cast from interface to interface, the less readable and consistent
> > the codebase becomes. Also, we have exposed much of our code as public
> > class + public method, even when APIs may not be intended as stable
> > extension points, for testing or other reasons. A few years ago, Hadoop
> > faced this problem and ended up implementing annotations to document APIs
> > as @Stable/@Evolving, @Public/@Limited/@Private. See <
> > https://issues.apache.org/jira/browse/HADOOP-5073> for the history on
> > that.
> >
> > I would like to propose the adoption of a similar mechanism in Flume, in
> > order to give us more wiggle room in the future for evolutionary
> > development. Thoughts?
> >
> > Right now, I feel we would get most of the bang for the buck simply by
> > adding two annotations: @Public and @Internal, which to me means "you can
> > subclass or instantiate this directly", or "you can't directly use this if
> > you expect future compatibility".
> >
> > Regards,
> > Mike
> >
>
>
>
> --
> Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/