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

[Aleksey Shipilev]

On 03/09/2016 12:53 PM, John Rose wrote:
> 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.

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.

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160309/d348b6e0/signature.asc>