mailto:common-dev@hadoop.apache.org>>
Subject: Re: Compatibility guidelines for toString overrides
On 14 May 2016, at 18:39, Allen Wittenauer
mailto:a...@apache.org>> wrote:
On May 12, 2016, at 12:20 PM, Chris Nauroth
mailto:cnaur...@hortonworks.com>> wrote:
Hello Allen,
The intent
On 14 May 2016, at 18:39, Allen Wittenauer
mailto:a...@apache.org>> wrote:
On May 12, 2016, at 12:20 PM, Chris Nauroth
mailto:cnaur...@hortonworks.com>> wrote:
Hello Allen,
The intent is not for this rule to override other compatibility rules,
such as the important CLI output rule. It's als
> On May 12, 2016, at 12:20 PM, Chris Nauroth wrote:
>
> Hello Allen,
>
> The intent is not for this rule to override other compatibility rules,
> such as the important CLI output rule. It's also not intended to give us
> free reign to change existing toString() implementations without due
> d
How about this idea:
Define a new annotation "StableImplUnstableInterface" which means consumers
can't assume stability but producers can't change things. Mark all toStrings
with this annotation.
Then, in a lazy fashion, as the need arises to change various toString methods,
diligence can be
As a downstream user of Hadoop, it would be much clearer if the
toString functions included the appropriate annotations to say they're
non-public, evolving, or whatever.
Most downstream users of Hadoop aren't going to remember in-detail
exceptions to the java API compatibility rules, once they see
> On 12 May 2016, at 17:57, Chris Nauroth wrote:
>
> I'm in favor of making a statement in the compatibility guidelines that
> there is no guarantee of stability or backwards-compatibility for
> toString() output. If a proposed patch introduces new dependencies on a
> stable toString() output,
Hello Allen,
The intent is not for this rule to override other compatibility rules,
such as the important CLI output rule. It's also not intended to give us
free reign to change existing toString() implementations without due
diligence. If a patch changes an existing toString() implementation th
-1 without an audit of every toString usage. We have recent examples (e.g.,
HDFS-9732) where toString was used for output from CLI utilities. (which, IMO,
should never have been done, but it’s too late now...) Output of CLI utilities
is most definitely covered by the compatibility guidelines.
+1.
Thanks,
Sangjin
On Thu, May 12, 2016 at 10:05 AM, Ravi Prakash wrote:
> Thanks sounds reasonable Colin. +1 to not using toString() as an API
>
> On Thu, May 12, 2016 at 9:57 AM, Chris Nauroth
> wrote:
>
> > I'm in favor of making a statement in the compatibility guidelines that
> > there i
Thanks sounds reasonable Colin. +1 to not using toString() as an API
On Thu, May 12, 2016 at 9:57 AM, Chris Nauroth
wrote:
> I'm in favor of making a statement in the compatibility guidelines that
> there is no guarantee of stability or backwards-compatibility for
> toString() output. If a prop
I'm in favor of making a statement in the compatibility guidelines that
there is no guarantee of stability or backwards-compatibility for
toString() output. If a proposed patch introduces new dependencies on a
stable toString() output, such as for UI display or object serialization,
then I'd consi
11 matches
Mail list logo
