RFR (S) 8151223: String concatenation fails with implicit toString() on package-private class
aleksey.shipilev at oracle.com
Wed Mar 9 10:41:00 UTC 2016
On 03/09/2016 01:18 PM, Aleksey Shipilev wrote:
> On 03/09/2016 12:53 PM, John Rose wrote:
>> Java binary compatibility rules also allow classes to change their
>> super type hierarchy over time.
>> So when you search up the super chain you are traversing links that
>> may not be present when the code is run. You are getting static
>> answers to questions about type relations which may have changed when
>> the code runs. This is one of JLS Chapter 13's favorite tricks. You
>> do not want it as your enemy.
As Maurizio points out to me privately, Ch. 13 actually spells out what
hierarchy changes are acceptable. Changing the hierarchy is such a way
that a leaf inaccessible class is not a subclass of a sharpened
accessible class anymore is *not* a binary compatible change, as per:
"Changing the direct superclass or the set of direct superinterfaces of
a class type will not break compatibility with pre-existing binaries,
provided that the total set of superclasses or superinterfaces,
respectively, of the class type loses no members."
I can get the reluctance of doing this for inaccessible classes, because
some handwaving may offer that "private" classes are "okay" to be
changed in incompatible manner. Therefore, I'd say we surrender the
discussion about the sharpest type for a very narrow corner case, and go
> Oops, too late for this particular bug, but we can file and work the
> followup. So, is this what you deem the safest route without sacrificing
> much of the type information?
> 1) Emit precise class for accessible classes;
> 2) Emit Object for inaccessible classes;
> 3) Do (1),(2) for array component types.
I am totally fine with current "sharpen to most specific accessible
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the compiler-dev