new StringBuilder(char)

Jeremy Manson jeremymanson at google.com
Tue Aug 19 06:22:04 UTC 2014


So, should Eddie submit a patch?  Someone on the Oracle side has to get it
through the API gatekeepers.

Jeremy


On Mon, Aug 18, 2014 at 1:30 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

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



More information about the core-libs-dev mailing list