And to expand on what Mikalai said, you probably should not ever subclass Thread. There are some cases where you need to do that, but they are very rare indeed. I understand this is an exercise, but just keep this in mind for future reference if you ever write concurrent code.
What both of them said, but I will take the opportunity to advocate for a practice we are allowed to do (not specific to threads) that I think often helps us read code quickly and understand what it does.
If this code in Pooler:
Without it, on a timed test where I was rushing, I might have made the same mistake that you did reading the first one (and I am planning to take the test!)
If I saw the @Override, which never changes the meaning of the code when you are overriding, but shows the reader of your code, "Hey, look over here!! This is an Override of an interface, abstract or concrete class method!" I would not have gotten it wrong. This is why I like them. Long ago, Java didn't have this, but it has for some time, and I find it causes me to make fewer mistakes when reading or writing code quickly under pressure.
RTFJD (the JavaDocs are your friends!) If you haven't read them in a long time, then RRTFJD (they might have changed!)
Please refer to the attached diagram. I put on a debugger and found out that t is thread-0, h is thread-1. thread-1 starts and runs its own run method and
thread-0 reference has nothing to do with thread-1 in this case.
Also, if you change your code into:
Then, h thread starts and executes t thread's run method. This is a typical way to execute a thread which is equivalent to :