Java's Thread Class Analogy

Just recently after a long  moment of absence in Android development,... i'm making a slow but definite come back with a refreshed perspective, so i believe ;-) .... and after diving onto android architecture sample,  I suspected my skills on concurrency programming was not that good....you guess what i did next, requested the Oracle for help, no not in Greece! And i learned something worth sharing from Thread Creation.

Here is what i learned from Java Thread. As the Java APIs are not open source :-( yet, why not make small workable examples, analogy classes that can mimic the Thread class, in return we get to understand more deeply about the APIs and have architecture style  like the pros .

According to Oracle documentation on Thread . there are two ways of working with threads.

1. the first one is providing a Runnable object to the thread constructor then calling thread's public method start(), simple ha?!
2.  the second one is extending  the Thread class, write your code in the run method. then instantiating the class and calling start method.

so how would the java elites managed the classes to do such sorcery . Curiosity is the mother of all  code refactoring
here is my class analogy after an hour of  experimentation.
i made simple classes SilkThread to mimic Thread class, Jumpable interface to mimic Runnable interface, and Jackie class that uses the #1 way and Jetli class that uses the #2 way.
the codes are very much self explanatory,
The SilkThread class implements Jumpable, as well as has aggregate reference to Jumpable, it can do both tasks(for sake of example). The class is used to initiate tasks that are needed by other classes in our cases kung-fu legends Jackie Chan and JetLi classes,



//SilkThread class for First and Second Option
public class SilkThread implements Jumpable{
    Jumpable person;
    public SilkThread() {
    }
    public SilkThread(Jumpable person) {
        this.person = person;
    }
    public void start(){
       
        if(person!=null)
            person.jump();
        else
            jump();
    }
    public void jump(){
        //super-class tasks
        System.out.println("within SilkThread...");
    }
   
}

******

public class JetLi extends SilkThread {
    public void jump() {
        super.jump();
        System.out.println("JetLi Extending SilkThread & Jumping");
       
    }
        public static void main(String[] args) {
            new JetLi().start();
        }

}

******
public class Jackie implements Jumpable{

    public static void main(String[] args) {
        new SilkThread(new Jackie()).start();

    }
    public void jump() {       
        System.out.println("Jackie Implementing & Jumping High");
    }

}
******
public interface Jumpable {
    void jump();
}

Lessons I learned,
The first option: Gives much flexibility, the Jumpable object  is ready to implement many other interfaces,  but the SilkThread class is acting only as a doorway  to your implemented method. It is limited.

The Second Option which is sub-classing the SilkThread's caveat is, you can't have your acting sub-classes  do any more extending other than SilkThreads' (can't extend more than one Class)... but the Super classes carries the burden of implementing Interfaces for you, It got your back, It can do many homework tasks before the sub-classes methods.
 For instances Letting the super class handle security related tasks first.
Yes, in the eyes of Thread implementation the first option has always been the #1 but in terms of design flexibility one should at least entertain the awesomeness of the second option.

P.S   Oracle has always the Answer 😅