Thread::getId final method

[Alan Bateman]

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