Thanks for the info! For the use case I found, the override does not make any sense and a final method would have allowed for an easy fix if that would have been the way this was discovered.
I think the method would make sense even before Loom. The overridable getter is also used in some MX beans what leads to weird exceptions there. Best regards, Rafael Alan Bateman <alan.bate...@oracle.com> schrieb am Fr., 25. März 2022, 10:10: > On 25/03/2022 08:18, Rafael Winterhalter wrote: > > Hello, > > > > I was recently debugging an issue where threads' ids were used to > identify > > an origin thread. The issue turned out to be that the getId method was > > overridden to return 0 for a row of threads in unrelated code, what broke > > that processing. > > > > I do now wonder if it would be a good idea to offer a new method on > > java.lang.Thread that returns the thread id but that is final. Possibly, > > getId should be deprecated in favour of that new method. > Loom lends on thread identifiers and adds a final Thread::threadId > method, deprecating the existing getId method. It's potentially > something that could be done at any time. > > As background, when JSR-174 added Thread::getId it was concerned that > adding a final method would be source and binary incompatible. At the > time, the thread identifier was only used for monitoring purposes and > wasn't a major issue if it were overridden to have different semantics. > > Since then, some libraries and tools have been making use of it. We did > look at the impact of doing the breaking change and making it final. A > static analysis of 100k artifacts found only one override, something in > Apache ZooKeeper. There may be others in the wild but this is the only > case found at the time. So on the surface it didn't seem to have a > significant impact but a breaking change none the less and we chickened > out of that approach. > > -Alan > >
