On Sun, 12 Apr 2026 03:56:47 GMT, Phil Race <[email protected]> wrote:
> > > Possibly discussed before, but I missed why we do not want to update
> > > DataBuffer class as well, to ensure any subclasses are validated?
>
> This PR is only concerned with the JDK concrete classes.
Why not the base *public* `DataBuffer` class?
> > Should `DataBuffer` be a **sealed** class?
>
> No. For multiple reasons. Including compatibility and extensibility by
> non-JDK classes. The latter reason means that even if sealed classes were
> available when this was designed it would not have been one.
Then the validation of `size`, `numBanks`, `offset` and `offsets` must be in
the `DataBuffer` class *“to ensure any subclasses are validated”*. Otherwise,
other subclasses could create instance of `DataBuffer` that break the
assumptions. For example, I can create a data buffer with negative size and an
invalid data type.
public class CustomBuffer extends DataBuffer {
public CustomBuffer(int size) {
super(128, size);
}
public CustomBuffer(int size, int numBanks) {
super(128, size, numBanks);
}
public static void main(String[] args) {
// Does not throw an exception for the invalid size
new CustomBuffer(-10);
// Throws NegativeArraySizeException because
// it creates an array for offsets: new int[numBanks]
new CustomBuffer(-10, -10);
}
}
Therefore, the `DataBuffer` constructors also have to specify the exceptions
for invalid parameters.
If the `DataBuffer` class was asealed and allowed only these specific set of
subclasses that the JDK provides, it would be fine since all these classes
validate the parameters now.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29766#issuecomment-4268362067
