The InputStream abstract class has FileInputStream and FilterInputStream as a direct subclass. FileInputStream has all necessary code to establish an input connection from a file, whereas FilterInputStream is created as a wrapper which acts as a decorator and facilitates other classes extending it to provide a specific and specialized operation on InputStream, hence BufferedInputStream is a subclass of it and provide buffering capabilities by introducing an in-memory byte-array which acts as a storage for reducing System input calls directly to the file-system. This complete hierarchy makes sense.

pictorial representation –

InputStream  ---> FileInputStream
            |
            |
             ---> FilterInputStream ---> BufferedInputStream

But then the Reader abstract class has FilterReader as a direct subclass but FileReader is not a direct subclass, FileReader extends InputStreamReader, and BufferedReader is a direct subclass of Reader and not of FilterReader, again why this decision is taken.

pictorial representation of this as well

Reader  ---> InputStreamReader ---> FileReader
       |
        ---> FilterReader
       |
        ---> BufferedReader

Let me summarize all my queries in bullet pointers for easy answering –

1. Why BufferedReader is a direct subclass of Reader and not extend FilterReader, as in the InputStream hierarchy.
2. Why does FileReader extend InputStreamReader and not directly a subclass of Reader ?
3. What capabilities were given to InputStreamReader because of which FileReader was kept a subclass of it?
4. Why are those capabilities of InputStreamReader not given to FilterReader? If it was done that way, maybe the Reader abstract class might have the same hierarchy as InputStream.
5. FilterReader might have been designed such that InputStreamReader can extend it and then provide an extra specialised wrapper on Reader for input-stream-specific purposes, which then can be further utilized. Why keep it a direct subclass instead?