[
https://issues.apache.org/jira/browse/ZOOKEEPER-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626673#comment-17626673
]
Chris Nauroth commented on ZOOKEEPER-4460:
------------------------------------------
[~AlanBateman] , thanks for the reply. I was misreading the {{QuorumPeer}}
code, because it has 2 different {{getId()}} methods thanks to a nested class.
It looks like we will have to address this. I'm not even sure that overriding
the thread ID was intentional so much as {{getId()}} was a natural method name
to use in this class that happens to extend {{{}Thread{}}}. (There is no
{{@Override}} annotation indicating intent.) I'll investigate if we can safely
change this.
> QuorumPeer overrides Thread.getId with different semantics
> ----------------------------------------------------------
>
> Key: ZOOKEEPER-4460
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4460
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Reporter: Alan Bateman
> Assignee: Chris Nauroth
> Priority: Major
>
> In OpenJDK, Project Loom has significantly re-implemented java.lang.Thread.
> One part of this is using some of the bits in the thread identifier for
> non-exposed purposes. Sadly, Thread::getId is not final and it's possible
> that sub-classes of Thread have overridden getId to have different semantics.
> The JDK can defend against this but there may be 3rd party libraries that
> make use of Thread::getId. A corpus search of Maven central found only one
> class: org.apache.zookeeper.server.quorum.QuorumPeer. Does this project know
> why getId has been overridden to return something that is not the thread
> identifier?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
