The layout of JournalSegmentDescriptor and its builder is weird.

The builder does not follow the Builder pattern at all assumes its methods will be called in the order in which the descriptor is to be layed out in the file – forcing users to specify withMaxEntries() even when that is not actually used.

Also UPDATED_LENGTH is not used, and SegmentDescriptor.update() checks 'locked' and is a no-op if locked is false.

All of this smells of rather huge trouble and lifecycle badness.

Analyze the ways the descriptor is actually used and bifurcate the mutable and non-mutable use cases.

The builder should cache set values, use some sane defaults or report ISE when something is not set and construct the ByteBuffer in proper order.

While we are at it, withMaxEntries() should be removed and a we should just write a (reasonably chosen) constant value.

Also, JournalSegmentDescritor.updated() seems to only reflect the last time the segment was open, running contrary to the JavaDoc of JournalSegmentDescriptor.updated(). At the end of the day, this information is largely unused. From semantics point of view, we certainly do not want to change this value every time we issue a write nor when we sync. This is largely a debug facility AFAICT, so perhaps it should be redefined as 'last time we cleanly closed this segment with modifications'? Needs further thought.