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

[John Rose]

Accessibility of the chosen class is only part of the headache you are signing up for.

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.

Basically, any static query done in javac has to be looked at with skepticism:  It can change, if the answer to the query does not come from either the current compilation unit, or else from the Java language runtime selected by the "-target" option of javac.

(Remi, this is why java.lang is special.  The Groovy compiler is welcome to make static assumptions about groovy.lang or whatever, but javac binds only to java.lang.)

My specific recommendation is not to ask questions with non-local answers in the static analysis of string operands.  Fail up to Object, or (if you can and you wish) to a java.lang type.


HTH
— John

----- Original Message -----
From: aleksey.shipilev at oracle.com
To: john.r.rose at oracle.com, forax at univ-mlv.fr
Cc: compiler-dev at openjdk.java.net
Sent: Tuesday, March 8, 2016 12:53:09 AM GMT -08:00 US/Canada Pacific
Subject: Re: RFR (S) 8151223: String concatenation fails with implicit toString() on package-private class

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.