JLS3 spec, chapter "17.4.9 Observable Behavior and Nonterminating Executions" says the following:
----------------------------------------------JLS3---------------------------------------------
"A thread can be blocked in a variety of circumstances, such as when it is attempting to acquire a lock or perform an external action (such as a read) that depends on external data. If a thread is in such a state, Thread.getState will return BLOCKED or WAITING."
-----------------------------------------------------------------------------------------------

But in API spec for enum java.lang.Thread.State there is written:
===================================================API for Thread.State=========================
public static final Thread.State *BLOCKED*

    Thread state for a thread blocked waiting for a monitor lock. A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method or reenter a synchronized block/method after calling Object.wait.

public static final Thread.State *WAITING*

    Thread state for a waiting thread. A thread is in the waiting state due to calling one of the following methods:

        * Object.wait with no timeout
        * Thread.join with no timeout
        * LockSupport.park

    A thread in the waiting state is waiting for another thread to perform a particular action. For example, a thread that has called Object.wait() on an object is waiting for another thread to call Object.notify() or Object.notifyAll() on that object. A thread that has called Thread.join() is waiting for a specified thread to terminate.

public static final Thread.State RUNNABLE

    Thread state for a runnable thread. A thread in the runnable state is executing in the Java virtual machine but it may be waiting for other resources from the operating system such as processor.

================================================================================================

According to API specification, in case if a thread perform an external action (such as a read) it can't be in the BLOCKED or WAITING state.
The test below confirms that if "System.out.read()" action is performed the thread is in the RUNNUBLE state.

----------------------TestCode-------------------------------------
import java.io.IOException;

public class Test {
    public static void main(String args[]) {
        Thread readThread = new Thread() {
            public void run() {
                try {
                    System.in.read();
                } catch (IOException e) {
                    System.out.println("IOException");
                }
            }
        };
        readThread.start();
        try {
            for (int i = 0; i < 100; i++) {
                System.out.println("i = " + i +
                        "; STATE = " + readThread.getState());
                Thread.sleep(100);
            }
        } catch (Exception e) {
        }
    }
}
-------------------------OutPut---------------------------------------
i = 0; STATE = RUNNABLE
i = 1; STATE = RUNNABLE
i = 2; STATE = RUNNABLE
i = 3; STATE = RUNNABLE
....
i = 98; STATE = RUNNABLE
i = 99; STATE = RUNNABLE
------------------------------------------------------------------------

So, there are contradictions between JLS3, api spec for Thread.getState and implementation.
It would be nice to resolve this issue. For lack of understanding, it is impossible to write new JCK tests for
this assertion.