Re: Compatibility guidelines for toString overrides

e.org<mailto:common-dev@hadoop.apache.org>" <common-dev@hadoop.apache.org<mailto:common-dev@hadoop.apache.org>> Subject: Re: Compatibility guidelines for toString overrides On 14 May 2016, at 18:39, Allen Wittenauer <a...@apache.org<mailto:a...@apache.org>> wro

Re: Compatibility guidelines for toString overrides

On 14 May 2016, at 18:39, Allen Wittenauer > wrote: 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

Re: Compatibility guidelines for toString overrides

> 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()

Re: Compatibility guidelines for toString overrides

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

Re: Compatibility guidelines for toString overrides

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

Re: Compatibility guidelines for toString overrides

> 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 >

Re: Compatibility guidelines for toString overrides

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

Re: Compatibility guidelines for toString overrides

-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

Re: Compatibility guidelines for toString overrides

+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

Re: Compatibility guidelines for toString overrides

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 >

Re: Compatibility guidelines for toString overrides

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

Compatibility guidelines for toString overrides

Hi all, Recently a discussion came up on HADOOP-13028 about the wisdom of overloading S3AInputStream#toString to output statistics information. It's a difficult judgement for me to make, since I'm not aware of any compatibility guidelines for InputStream#toString. Do we have compatibility