Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171

Rafael Winterhalter rafael.wth at
Fri Apr 27 18:23:19 UTC 2018

Hei Alan and David,
thanks for pointing me to the issue, I have only searched the release notes
for u172 by accident.

The issue is mainly during builds. I run my library on multiple CI servers
to cover Windows/Linux and different Java versions from 6-11.
Unfortunately, I have not full control over what version of Java is run on
these servers. Yesterday, I found some of the builds fail for pull requests
what was a bit confusing. Byte Buddy offers an abstraction over type
descriptions that implement similar semantics to the Java reflection API
when it comes to equality and to textual (toString) representations. These
tests suddenly failed since the JVMs representation is changed, this is
all. The Scala build had a similar problem:

This is not a big deal but I found it surprising to have a change in the
string representation within an update release. Especially since a nested
class does not necessarily have the same name prefix if a class is not
compiled with javac. I would have preferred the consistency over the
redundancy; especially when type names are machine-processed, this often
makes a parser easier to implement.

Thanks for clarifying this for me, best regards,

2018-04-27 11:38 GMT+02:00 Alan Bateman <Alan.Bateman at>:

> On 27/04/2018 10:10, David Holmes wrote:
>> Hi Rafael,
>> On 27/04/2018 6:12 PM, Rafael Winterhalter wrote:
>>> Hello,
>>> I was wondering if the change in ParameterizedType::toString was
>>> intended.
> See also the discussion from June 2016 [1] on this change.
> I can't tell from your mail if it's the repeated class name or the "$"
> issue that is causing you (and Scala) issues.
> -Alan
> [1]
> ne/041869.html

More information about the core-libs-dev mailing list