Page History

...

These are the key interfaces used by clients of the framework:

@startuml
class SomeApplicationClass {
}

interface AutoCloseable {
void close()
}
interface ByteBufferSharing extends AutoCloseable {
ByteBuffer getBuffer()
ByteBuffer expandWriteBufferIfNeeded(int newCapacity)
ByteBuffer expandReadBufferIfNeeded(int newCapacity)
}

class ByteBufferVendor {
ByteBufferVendor(ByteBuffer bufferArg, BufferType bufferType, BufferPool bufferPool)
ByteBufferSharing open()
ByteBufferSharing open(long time, TimeUnit unit)
void destruct()
}

SomeApplicationClass "vendor" *-- ByteBufferVendor
ByteBufferVendor "sharing" *-- ByteBufferSharing
ByteBufferVendor .. ByteBuffer : derived\nassociation
@enduml

In the diagram SomeApplicationClass is a class outside the framework, that needs shared ByteBuffers. SomeApplication class has a field holding a ByteBufferVendor. The object referenced by that field is constructed by SomeApplicationClass and when that class is done with the ByteBuffer it calls ByteBufferVendor.destruct().

When SomeApplicationClass needs to access the ByteBuffer it calls ByteBufferVendor.open() as part of a ByteBufferSharing implements AutoCloseable so it's usable as a resource in try-with-resources . It's this interface that a user of ByteBuffers will be most interested invariable declaration. Inside the scope of that try-with-resources block, the thread has exclusive access to the ByteBufferSharing object, and to its associated ByteBuffer.

The try-with-resources machinery works because ByteBufferSharing implements AutoCloseable. Within the scope of a try-with-resources block, client code accesses ByteBuffer functionality through the ByteBufferSharing interface:

ByteBuffer getBuffer()
ByteBuffer expandWriteBufferIfNeeded(int newCapacity)
ByteBuffer expandReadBufferIfNeeded(int newCapacity)

...