RFR (S) 8151223: String concatenation fails with implicit toString() on package-private class

[Maurizio Cimadamore]

Here's an extreme case where sharpening can end up in some weird case in 
a binary compatible scenario; quoting chapter 13:

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

So, let's start with:

public class A { }

class Inaccessible extends A { }

Here, the sharpening method would lift 'Inaccessible' to 'A'.

Now, let's change that as follows:

public class A { }
public class B extends A { }

class Inaccessible extends B { }

Now, the sharpening method will lift 'Inaccessible' to 'B'.

Is this an issue? While I don't think it's a big issue, it also means 
that the runtime cannot totally rely on the static information put there 
by javac, as this information might as well be stale (as in the above 
case, where a classfile says 'A' where in fact the sharpest type is 
'B'). Of course this can happen even w/o accessibility woes, so we 
should probably not worry about this?

Maurizio

On 08/03/16 08:53, Aleksey Shipilev wrote:
> On 03/08/2016 05:34 AM, John Rose wrote:
>> The more cleverly we use static information when generating
>> bytecodes, the more murky will be our binary compatibility story. I
>> suggest you rely mainly on locally available metadata (caller class
>> and its nest) and on stable packages (java.lang). Any uncertainty
>> should send the argument type all the way to Object. Dynamic type
>> profiling will pick up some of the dropped bits and we won't have
>> binary compat. puzzles to solve down the road. Like the present bug.
> Not really sure what you are suggesting to do right now, John.
>
> I think sharpening to the most specific accessible class is okay,
> because JLS Chapter 13 "Binary Compatibility" clearly points out that
> changing the visibility of classes/members to less access may be binary
> incompatible. IOW, once you compiled against an accessible class, it is
> a maintainers' headache to preserve compatibility.
>
> -Aleksey
>