That one is not supposed to be abstract, it is supposed to be concrete.
You cannot instantiate an abstract class, so in order to demonstrate the extends and nesting I needed to create the two concrete classes. That is very important in order to show the instantiation of the nested classes.
The simplest way to look at the abstract is a skeleton shell. It doesn't know anything other than the absolute basics of what it should be representing. If you have an animal for example ('scuse the example my biology classes are well over a decade behind me so terms are fleeting) you could track the Kingdom, but that's about it. You can then superclass that to another class which may be concrete or abstract which represents the phylum or class, and work down the chain of refinement until you get to the species (which is the bottom so now you need to actually use a concrete). You can implement as many concrete or abstract methods as you want down the chain. Most of these can be implemented to the top level abstract Animalia, so at minimum you'll be able to get the kingdom, phylum, class, uhhh, order? and ultimately down to species. This means you can typecast against the highest abstract (or interface)(perhaps not a great example since you could just as easily use properties):
public abstract class Animalia
public String getKingdom()
public abstract Phylum getPhylum();
public abstract Order getOrder();
//. . .
//. . .
public Phylum getAnimaliaPhylum(Animalia a)
Since you know you cannot instantiate an Animalia directly, whatever is provided in Animalia for the getAnimaliaPhylum guarantees that you can fetch the .getPhylum on the instance of Animalia a.
One of the best usages of the abstracts is to create the base container for multiple interfaces. Take as many interfaces as you want to implement (but not constantly rewrite) and drop them into an abstract. Refine as needed.