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

John Rose john.r.rose at oracle.com
Thu Mar 10 23:42:21 UTC 2016


Ok, now I mostly agree with Rémi and Maurizio. If a static search finds a super, we can assume that super will be present at runtime; so says Ch.13. The assumption of accessibility (of that chosen super) requires additional assurances which are (probably) in the spirit of 13 but not the letter. 

Here's my preference: Unless there is language in 13 guaranteeing accessibility of supers to clients (unlikely, but Maurizio can find it if it is there) then we should treat all supers as possibly-inaccessible (at runtime) except 1) those in the nest (compilation unit) of the class containing the indy call and 2) those in java.lang, which includes good old Object as a fallback. And 3) arrays thereof. 

Supers in the same package but not in the same nest, or in other package, if not java.lang, cannot be trusted to be accessible at runtime. Example: someone refactors a package-local super to be public and later refactors it non-public to reduce exports. Happens all the time. 

– John

On Mar 9, 2016, at 6:17 AM, Remi Forax <forax at univ-mlv.fr> wrote:

>> provided that the total set of superclasses or superinterfaces,
>> respectively, of the class type loses no members.


More information about the compiler-dev mailing list