The stream-based methods are not well-designed:

1. A library should not define a wire protocol and assume the peer is using the same. http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-05 requires the application to define it.

2. It's impossible to implement these methods correctly when the mechanism token has no self-framing or the library has no knowledge of the token format (for example, as a bridge talking to another GSS library).

RFC 8353 has thus removed these methods.

In Oracle JDK and OpenJDK, we will mark these methods as @deprecated. The existing implementations will not be changed. If we add a new mechanism later that does not have a self-framing, the methods will consume all bytes available and treat them as the input token. In fact, today probably the only correct usage of these methods is to read the application level header first, find out the token length, and create a single-shot "bounded" InputStream for the whole token. Such a solution will continue to work.

Loosely speaking, the spec of these methods should have been: "This method tries (not its best) to find out where the next token ends and consumes the token, otherwise it consumes all bytes available and treats it as a single token. The behavior is unspecified if the method has a knowledge (could be wrong) of the token length but cannot read enough bytes from the stream".