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.bate...@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 >
