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

Remi Forax forax at univ-mlv.fr
Mon Mar 7 21:33:28 UTC 2016


Hi Aleksey,
I think that trying to get the most specific type in that case is a good idea but
i think that trying to find the most specific interface(s) is useless.

Calling a method on an interface will always be resolved at runtime,
moreover, it's not possible to create a default method overriding Object.toString()
so i believe that calling toString() on an interface is equivalent to calling toString on Object in term of type information.

cheers,
Rémi

----- Mail original -----
> De: "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
> À: compiler-dev at openjdk.java.net
> Envoyé: Lundi 7 Mars 2016 19:46:27
> Objet: RFR (S) 8151223: String concatenation fails with implicit toString()	on package-private class
> 
> Hi,
> 
> There seems to be a corner case in our current String concatenation
> handling: we are recording the exact argument types to call
> StringConcatFactory with, to allow JDK to use that information for
> optimization. This works well, until we meet a private class. Then, we
> get an IllegalAccessError while trying to execute a bootstrap method
> referencing an inaccessible class:
>    https://bugs.openjdk.java.net/browse/JDK-8151223
> 
> This does not happen with "old" concat flavor, because we are calling
> StringBuilder.append(Object) there, which does not leak away the private
> type.
> 
> Luckily, we are not mandated to always call StringConcatFactory with an
> exact type. We can detect inaccessible classes during compilation, and
> use the closest accessible super-type instead. We could just strip to
> java.lang.Object in those cases, but it seems better to sharpen the type
> to the first accessible/non-ambiguous class/interface up the hierarchy.
> 
> Webrev:
>    http://cr.openjdk.java.net/~shade/8151223/webrev.01
> 
> Testing: failing test, new regression test; JDK java/lang/String;
> Langtools com/,jdk/,tools/
> 
> Thanks,
> -Aleksey
> 
> 


More information about the compiler-dev mailing list