Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171

[Rafael Winterhalter]

Yes, of course, the behavior is not specified in this detail but the
implementation has been stable what I argue makes sense due to the
possibility of automatic processing by low-level tools.

It is not a big problem, it just surprised me that the implementation
changed and I was wondering about the motivation since I did not spot the
ticket.

Thanks for pointing me in the right direction.

Best regards, Rafael

2018-04-28 9:51 GMT+02:00 Alan Bateman <Alan.Bateman at oracle.com>:

> On 27/04/2018 19:23, Rafael Winterhalter wrote:
>
>> 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:
>> https://github.com/scala/bug/issues/10835
>>
>> 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.
>>
> There isn't sufficient information in the bug to understand why it was
> back-ported to 8u172. That said, aren't you replying on unspecified
> behavior? I don't think toString is specified here.
>
> -Alan
>