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