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 <jeremyman...@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 <eaf...@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
