WebSocket.Builder.connectTimeout(long timeout, TimeUnit unit) implicitly affect websocket connection timeout

According the javadoc, the method is "
Sets a timeout for the opening handshake.

If the opening handshake is not finished within the specified timeout then buildAsync() completes exceptionally with a HttpTimeoutException.

If the timeout is not specified then it's deemed infinite.
"
According with the test, it actually affects not only opening handshake but also the underlying connection.

This is a snippet of code. I will attach a whole version too.

        CompletableFuture<WebSocket> future = WebSocket
                .newBuilder(
                        URI_to_ws_endpoint,
                        A_Listener)
                .connectTimeout(5, TimeUnit.SECONDS) //Specify connectTimeout for opening handshake
                .buildAsync();
        WebSocket ws = future.get();
        //Make sure handshake succeeded
        ws.sendText("Hello");
        //Indicate how timeout affects
        Thread.sleep(6000);//Wait for a moment
        System.out.println("isClosed:" + ws.isClosed());
        ws.sendText("Hello again").get();

isClosed() returns false.
But it will throw following exception when trying to sendText:
Caused by: java.nio.channels.ClosedChannelException^M
        at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(java.base@9-internal/SocketChannelImpl.java:272)^M
        at sun.nio.ch.SocketChannelImpl.write(java.base@9-internal/SocketChannelImpl.java:496)^M
        at java.net.http.PlainHttpConnection.write(java.httpclient@9-internal/PlainHttpConnection.java:139)^M
        at java.net.http.RawChannel.write(java.httpclient@9-internal/RawChannel.java:147)^M
        at java.net.http.WSWriter.completeWrite(java.httpclient@9-internal/WSWriter.java:96)^M
        at java.net.http.WSWriter.write(java.httpclient@9-internal/WSWriter.java:86)^M
        at java.net.http.WSMessageSender$1.visit(java.httpclient@9-internal/WSMessageSender.java:148)^M
        at java.net.http.WSMessageSender$1.visit(java.httpclient@9-internal/WSMessageSender.java:110)^M
        at java.net.http.WSOutgoingMessage$Text.accept(java.httpclient@9-internal/WSOutgoingMessage.java:57)^M
        at java.net.http.WSMessageSender.completeSend(java.httpclient@9-internal/WSMessageSender.java:104)^M
        at java.net.http.WSMessageSender.send(java.httpclient@9-internal/WSMessageSender.java:91)^M
        at java.net.http.WSMessagePublisher.react(java.httpclient@9-internal/WSMessagePublisher.java:89)^M
        at java.net.http.WSSignalHandler.lambda$new$1(java.httpclient@9-internal/WSSignalHandler.java:80)^M
        at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-internal/ThreadPoolExecutor.java:1158)^M
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-internal/ThreadPoolExecutor.java:632)

I'm not sure if this is expected behavior. But it is indeed surprising.

Not sure what is the method or policy to decide a websocket connection to be alive. Actually, I didn't find an timeout concept for the websocket in javadoc, except connectTimeout for opening handshake.

I suppose it is related with the timeout specified in HttpRequest.