Skip to content

Conversation

@JaroslavTulach
Copy link
Member

Pull Request Description

  • follow up of Storing LocalDate in off-heap IntBuffer #14652 for your consideration @jdunkerley
  • the vision currently is:
    • ValidityBuffer is responsible for handling null values
    • subclasses are supposed to be handling the real values
  • the vision is compromised by poor encapsulation of currentSize field
  • this PR makes currentSize field private, but ...
  • the consequences are huge
    • the changes affect appendLong, appendDouble & co.
  • I don't feel I want to do such a refactoring on my own...

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • All code follows the
    Java,
  • Unit tests are fine

@JaroslavTulach JaroslavTulach added the -libs Libraries: New libraries to be implemented label Jan 20, 2026
@JaroslavTulach JaroslavTulach marked this pull request as draft January 20, 2026 06:13
Copy link
Member Author

@JaroslavTulach JaroslavTulach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

James, here is description of the refactoring motivations, decisions and doubts that made me turn this PR into a draft. Please take a look. Probably also take it over, as I doubt I understand the implications of the change.

permits DoubleBuilder, LongBuilder, DateBuilder {
private BitSet validityMap;
int currentSize;
private int currentSize;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • encapsulating this currentSize field is the main goal of this PR, @jdunkerley

try {
appendAt(currentSize, o);
this.setValid(currentSize);
currentSize++;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • however, if currentSize is private, then
  • these manipulations of the field must be in ValidityBuffer
  • hence moving append here
  • it is not a bad refactoring as most of the append implementations are copies of themselves
  • but of course, ValidityBuffer only handles null values by itself
  • hence we need a seam - e.g. appendAt

resize(desiredCapacity);
}

protected abstract void appendAt(int index, Object value);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • this is the seam for subclasses to hook in
  • and somehow store the provided value into their storage (e.g. IntBuffer, etc.)

}

private int currentSize() {
return Math.toIntExact(getCurrentSize());
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • off topic, but:
  • the fact that we use int as index, but return long from getCurrentSize() is very annoying
  • I assume the original intention was to allow huge storages, but
  • when the builders use int everywhere else, it just stays in the way
    • as the proliferation of various Math.toIntExact or (int) casts demonstrates
  • wouldn't it be easier to make it int getCurrentSize(), @jdunkerley?

ensureSpaceToAppend();
setValid(currentSize);
data.put(currentSize++, value);
append(value);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • this is the place where I started to doubt I am doing the right refactoring
  • DoubleBuilder cannot access currentSize directly
    • as the goal is to encapsulate all the currentSize manipulation in ValidityBuffer
  • so the only thing it can do is to delegate to ValidityBuffer.append and wait for a appendAt callback
  • but that all renders all these appendDouble, appendLong useless...

@JaroslavTulach JaroslavTulach added the CI: No changelog needed Do not require a changelog entry for this PR. label Jan 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

-libs Libraries: New libraries to be implemented CI: No changelog needed Do not require a changelog entry for this PR.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants