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
