new StringBuilder(char)

[Joe Darcy]

As a general comment, in a new platform release like Java SE 9, it can 
be acceptable to add new overrides that would change the meaning of 
existing code:

http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy

Truth be told, we've sometimes adding new methods which changes client 
code behavior accidentally, such as:

     JDK-6226858: NoSuchMethodError in BigDecimal when compiling with 
1.5 targetted for 1.4
     https://bugs.openjdk.java.net/browse/JDK-6226858

Cheers,

-Joe

On 08/18/2014 12:02 PM, Mike Duigou wrote:
> On Aug 15 2014, at 22:38 , Jeremy Manson <jeremymanson at google.com> wrote:
>
>> No love from core-libs-dev?
> Pavel has been looking into this and doing corpus and historical bug checks. It seems possible that we might consider fixing it as it does seem to be an ongoing source of errors.
>
> Mike
>
>>   It's backwards-incompatible, but in a way that
>> would unbreak existing broken code.  Might be a worthwhile cleanup.
>>
>> Jeremy
>>
>>
>> On Fri, Aug 8, 2014 at 1:53 PM, Eddie Aftandilian <eaftan at google.com> wrote:
>>
>>> Hi all,
>>>
>>> We recently realized that calling new StringBuilder(char) does not do what
>>> you would think it does.  Since there is no char constructor defined, the
>>> char is widened to an int and the StringBuffer is presized to the
>>> character's encoded value.  Thus code like this prints an empty string
>>> rather than the expected "a":
>>> System.out.println(new StringBuilder('a'));
>>>
>>> Would it be possible to add a char constructor to StringBuilder to prevent
>>> this problem? I understand this would change the behavior of any code that
>>> is currently doing this, but it's hard to imagine anyone doing this
>>> intentionally.  Of the ~20 instances we found in Google's codebase, all
>>> were bugs.  What is your policy on making changes like this where (a) it
>>> will cause a change in behavior, but (b) the currently behavior is clearly
>>> wrong?
>>>
>>> If you're willing to take the change, I'd be happy to send a patch.
>>>
>>> Thanks,
>>> Eddie
>>>