Why java doesn't give a bit read api?

Question

I am using java ByteBuffer to save some basic data into streams. One situation is that I must transfer a "Boolean list" from one machine to another through the internet, so I want the buffer to be as small as possible.
I know the normal way of doing this is using buffer like this:

    public final void writeBool(boolean b) throws IOException {
        writeByte(b ? 1 : 0);
    }
    public final void writeByte(int b) throws IOException {
        if (buffer.remaining() < Byte.BYTES) {
            flush();
        }
        buffer.put((byte) b);
    }


    public boolean readBool(long pos) {
        return readByte(pos) == 1;
    }

    public int readByte(long pos) {
        return buffer.get((int)pos) & 0xff;
    }

This is a way of converting a boolean into byte and store into buffer. But I'm wandering, why not just putting a bit into buffer, so that a a byte can represent eight booleans, right?
The code maybe like this? But java doesn't have a writeBit function.

    public final void writeBool(boolean b) throws IOException {
        // java doesn't have it.
        buffer.writeBit(b ? 0x1 : 0x0);
    }
    public final boolean readBool(long pos) throws IOException {
        // java doesn't have it
        return buffer.getBit(pos) == 0x01;
    }

So I think the only way doing that is "store eight booleans into a byte and write",like ((0x01f >>> 4) & 0x01) == 1 to check if the fifth boolean is true. But if I can get a byte, why not just let me get a bit?
Is there some other reason that java cannot let us operate bit?

Answer 1

Yeah, so I mean why not create a BitBuffer?

That would be a question for the Java / OpenJDK development team, if you want a definitive answer. However I expect they would make these points:

1. Such a class would have extremely limited utility in real applications.

2. Such a class is unnecessary given that an application doing (notionally) bit-oriented I/O can be implemented using ByteBuffer and a small amount of "bit-twiddling"

3. There is the technical issue that main-stream operating systems, and main-stream network protocols only support I/O down to the granularity of a byte¹. So, for example, file lengths are recorded in bytes, and creating a file containing precisely 42 bits of data (for example) is problematic.

Anyway, there is nothing stopping you from designing and writing your own BitBuffer class; e.g. as a wrapper for ByteBuffer. And sharing it with other people who need such a thing.

Or looking on (say) Github for a Java class called BitBuffer.

---

^{1 - Indeed I don't know of any operating system, file system or network protocol that has a smaller granularity than this.}