Flatten bytes class hierarchy by lu-pinto · Pull Request #40 · Consensys/tuweni

lu-pinto · 2025-03-04T15:58:29Z

PR description

This PR simplifies the Tuweni class hierarchy of the bytes project and attempts to get some performance gains by reducing memory churn, specially for copying byte arrays and Bytes instances. Bytes have now a much flatter class hierarchy that will hopefully improve inlining and reduce time on itable lookups which was identified as one of the problems in Besu for low performance. The implementation of Bytes used at runtime is now highly biased towards ArrayWrappingBytes which makes it easier for JIT to inline and optimize.

Also mutable operations wil be moved into MutableBytes exclusively to show intention in copies. This avoids copies on sequences of logic operations, e.g. MutableBytes.create(10).or(Bytes.fromHex("0x11")).shiftRight(2) no further copies occur after initial instance creation.
Other Bytes subtypes should be immutable from now on to boost performance.

Note

Introduces a new, flatter org.apache.tuweni.v2.bytes API and adds benchmarking support.

Adds core v2 classes: Bytes, MutableBytes, ArrayWrappingBytes, ConcatenatedBytes, ConstantBytesValue, DelegatingBytes, Utils, size-specific Bytes32/Bytes48, and wrappers for ByteBuffer/ByteBuf/Vert.x Buffer
Centralizes mutating ops in MutableBytes; other Bytes implementations are immutable
Implements slicing, prefix/trim utilities, numeric conversions, (de)serialization helpers, and efficient logical ops
Enables JMH via Gradle (conditional on src/jmh), with config, async-profiler support, and adds two benchmarks (BytesMegamorphicBenchmarkV1/V2)
Expands tests for v2 (buffer/bytebuf/bytebuffer/concat/delegate/bytes32/bytes48) and updates an existing concat test; adds assertj-core test dependency

^{Written by Cursor Bugbot for commit a646271. This will update automatically on new commits. Configure here.}

github-actions · 2025-03-04T15:58:41Z

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

lu-pinto · 2025-03-04T16:00:07Z

I have read the CLA Document and I hereby sign the CLA

lu-pinto · 2025-03-04T16:00:26Z

recheck

lu-pinto · 2025-05-21T13:05:07Z

After this comment I will make this PR ready to be pulled in without stopping any development on Tuweni v1 as I'm leaving the current org.apache.tuweni namespace untouched.

I will squash all changes so far and will create an entire new package org.apache.tuweni.v2 which contains the new class hierarchy for Tuweni along with all of its dependents.

lu-pinto · 2025-05-22T12:51:40Z

recheck

macfarla

do we need to add a consensys copyright statement? Are both v1 and v2 tests running?

bytes/src/jmh/java/org/benchmark/VirtualCall.java

bytes/src/main/java/org/apache/tuweni/v2/bytes/ArrayWrappingBytes.java

bytes/src/test/java/org/apache/tuweni/bytes/ConcatenatedBytesTest.java

bytes/build.gradle

bytes/src/jmh/java/org/benchmark/ProfiledBenchmark.java

bytes/src/main/java/org/apache/tuweni/v2/bytes/ArrayWrappingBytes.java

github-actions · 2025-06-18T05:17:03Z

This PR was marked stale due to lack of activity. It will be closed in 14 days.

bytes/src/jmh/java/org/benchmark/ProfiledBenchmark.java

bytes/build.gradle

bytes/src/jmh/java/org/benchmark/InterfaceCall.java

bytes/src/jmh/java/org/benchmark/VirtualCall.java

bytes/build.gradle

bytes/src/jmh/java/org/benchmark/BytesMegamorphicBenchmarkV1.java

bytes/src/jmh/java/org/benchmark/BytesMegamorphicBenchmarkV2.java

ahamlat · 2025-06-23T08:34:12Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ArrayWrappingBytes.java

+    if (offset == 0 && length == bytes.length) {
+      return bytes;
+    }
+    return Arrays.copyOfRange(bytes, offset, offset + length);


I understand to toArray() is removed, correct ?

Yes, I'm not convinced it's needed. At least not needed for tuweni or discovery so far

bytes/src/main/java/org/apache/tuweni/v2/bytes/ArrayWrappingBytes.java

bytes/src/main/java/org/apache/tuweni/v2/bytes/BufferWrappingBytes.java

ahamlat · 2025-06-23T08:49:26Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ArrayWrappingBytes.java

+
+  @Override
+  protected void and(byte[] bytesArray, int offset, int length) {
+    Utils.and(this.bytes, this.offset, bytesArray, offset, length);


It would be nice to have jmh benchmarks on and other binary operations below. I think it will show a pretty good improvement. This is not a blocking comment, but a nice to have.

let's do that in another PR

ahamlat · 2025-06-23T09:16:40Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/DelegatingBytes.java

+ * <p>This class may be used to create more types that represent bytes, but need a different name
+ * for business logic.
+ */
+public class DelegatingBytes extends Bytes {


shiftLeft and shiftRight doesn't exist anymore in this implementation, is that intended ?

yes, I have moved all to the MutableBytes. Now can do multiple operations on Bytes and avoid copying and we are explicit that we are creating copies

ahamlat · 2025-06-23T09:17:08Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ArrayWrappingBytes.java

+  protected void xor(byte[] bytesArray, int offset, int length) {
+    Utils.xor(this.bytes, this.offset, bytesArray, offset, length);
+  }
+


Does it make sens to add shiftLeft and shiftRight here ?

same as #40 (comment)

ahamlat · 2025-06-23T09:24:20Z

bytes/src/main/java/org/apache/tuweni/bytes/v2/Bytes32.java

+import java.util.Random;
+
+/** A {@link Bytes} value that is guaranteed to contain exactly 32 bytes. */
+public final class Bytes32 extends DelegatingBytes {


I suggest to rename this class DelegatingBytes32.

Why though? That's an implementation detail

ahamlat · 2025-06-23T09:24:43Z

bytes/src/main/java/org/apache/tuweni/bytes/v2/Bytes48.java

+import java.util.Random;
+
+/** A {@link Bytes} value that is guaranteed to contain exactly 48 bytes. */
+public final class Bytes48 extends DelegatingBytes {


I suggest renaming this class DelegatingBytes48.

same as #40 (comment)

ahamlat · 2025-06-23T09:37:28Z

bytes/src/main/java/org/apache/tuweni/bytes/v2/Bytes48.java

+      return bytes48;
+    }
+    checkArgument(slice.size() == SIZE, "Expected %s bytes but got %s", SIZE, slice.size());
+    return new Bytes48(slice.getImpl());


Why mot just new Bytes48(slice) ?

I see, because of DelegatingBytes. I wonder if is not simpler to have another overloaded method with DelegatingBytes as a parameter and delete getImpl() in Bytes.java.

Correct, because of DelegatingBytes so we need to get straight access to the implementation to avoid stacked method call that just loops.
Not sure I understand the suggestion - do you mean casting Bytes to DelegatingBytes ?

bytes/src/main/java/org/apache/tuweni/v2/bytes/ConcatenatedBytes.java

ahamlat · 2025-06-23T09:57:39Z

bytes/src/main/java/org/apache/tuweni/bytes/v2/ConcatenatedBytes.java

+    for (Bytes value : values) {
+      int size = value.size();
+      try {
+        totalSize = Math.addExact(totalSize, size);


Instead of throwing and then catching the exception, I suggest replacing with the code of Math.addExact :

int result = totalSize + size; // HD 2-12 Overflow iff both arguments have the opposite sign of the result if (((totalSize ^ result) & (size ^ result)) < 0) { throw new IllegalArgumentException( "Combined length of values is too long (> Integer.MAX_VALUE)"); } totalSize = result;

but are you sure the method is not going to be inlined anyway? I would suggest creating a benchmark to prove that

ahamlat · 2025-06-23T10:09:52Z

I can confirm that the V2 implementations has better performance for megamorphic use case and similar performances for the non megamorphic one

Benchmark                         (mode)  Mode  Cnt   Score   Error  Units
BytesMegamorphicBenchmarkV1.test    mono  avgt   10   6.774 ± 0.351  ms/op
BytesMegamorphicBenchmarkV1.test    mega  avgt   10  15.024 ± 0.225  ms/op
BytesMegamorphicBenchmarkV2.test    mono  avgt   10   6.591 ± 0.189  ms/op
BytesMegamorphicBenchmarkV2.test    mega  avgt   10   9.899 ± 0.070  ms/op

ahamlat · 2025-06-23T10:14:43Z

crypto/src/main/java/org/apache/tuweni/crypto/Hash.java

+  public static Bytes keccak256(Bytes input) {
    try {
-      return (Bytes32) digestUsingAlgorithm(input, KECCAK_256);
+      return digestUsingAlgorithm(input, KECCAK_256);


In this case, we're loosing the information that the returned Bytes from keccak256 is 32 bytes. I wonder if there're edge cases to this, as Bytes can store more than 32 bytes.

I agree you loose the developer friendliness. Though for performance might be justified. Anyway, we are leaving both versions of the code in anyways so we have time to decide after this PR, IMO

ahamlat · 2025-06-23T10:15:03Z

crypto/src/main/java/org/apache/tuweni/crypto/Hash.java

+  public static Bytes sha3_256(Bytes input) {
    try {
-      return (Bytes32) digestUsingAlgorithm(input, SHA3_256);
+      return digestUsingAlgorithm(input, SHA3_256);


The same as for keccak256

github-actions · 2025-07-08T05:17:11Z

This PR was marked stale due to lack of activity. It will be closed in 14 days.

github-actions · 2025-10-23T05:17:06Z

Closed as inactive. Feel free to reopen if this PR is still being worked on.

cursor · 2025-10-30T01:22:57Z

units/src/main/java/org/apache/tuweni/v2/units/bigints/UInt256.java

+      result[i] = this.ints[i] & other;
+    }
+    return new UInt256(result);
+  }


Bug: Bitwise Operation Errors in UInt Classes

The and, or, and xor methods in both UInt256 and UInt384 classes contain a byte indexing error when operating on Bytes or Bytes32 parameters. The byte offset calculation incorrectly uses the ints array index (i) instead of the bytes parameter index (j), leading to incorrect bitwise results and potential IndexOutOfBoundsException.

Additional Locations (4)

units/src/main/java/org/apache/tuweni/v2/units/bigints/UInt384.java#L457-L464

units/src/main/java/org/apache/tuweni/v2/units/bigints/UInt384.java#L487-L494

units/src/main/java/org/apache/tuweni/v2/units/bigints/UInt384.java#L519-L526

units/src/main/java/org/apache/tuweni/v2/units/bigints/UInt256.java#L637-L644

cursor · 2025-10-30T01:22:57Z

devp2p/src/main/kotlin/org/apache/tuweni/v2/devp2p/Packet.kt

+    fun create(keyPair: SECP256K1.KeyPair, now: Long): Packet {
+      val expiration = expirationFor(now)
+      val sigHash = createSignature(
+        PacketType.ENRRESPONSE,


Bug: Packet Signature Mismatch Causes Verification Failures

The ENRRequestPacket.create() method uses PacketType.ENRRESPONSE for the packet signature. This is inconsistent with the encode() method's use of PacketType.ENRREQUEST and will cause signature verification failures for ENRRequest packets.

cursor · 2025-10-30T01:22:57Z

crypto/src/main/java/org/apache/tuweni/v2/crypto/Hash.java

+      try {
+        SHA256Hash.Hash result = SHA256Hash.hash(shaInput);
+        try {
+          return SHA256Hash.hash(shaInput).bytes();


Bug: Double Hashing Causes Memory Leak

The sha2_256 methods (both byte[] and Bytes overloads) compute the hash twice when Sodium is available. The first hash object is stored and destroyed, but a new hash object is created and returned from a second computation, which is then leaked.

Additional Locations (1)

crypto/src/main/java/org/apache/tuweni/v2/crypto/Hash.java#L106-L107

github-actions · 2025-11-13T05:17:16Z

This PR was marked stale due to lack of activity. It will be closed in 14 days.

cursor · 2025-11-13T10:51:59Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Bytes32.java

+      checkElementIndex(offset, bytes.length);
+    }
+    checkLength(bytes, offset);
+    return new ArrayWrappingBytes(bytes, offset, bytes.length);


Bug: Array Wrapper Overruns Bounds: Incorrect Length

The fromArray method creates an ArrayWrappingBytes with bytes.length as the length parameter, which attempts to wrap more bytes than available when offset > 0. This causes the wrapper to extend beyond the array bounds. The length should be SIZE (32 bytes) to correctly wrap exactly 32 bytes starting from the offset, matching the method's documented behavior and the validation performed by checkLength.

cursor · 2025-11-13T10:51:59Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ByteBufferWrappingBytes.java

+  @Override
+  public void appendTo(ByteBuffer byteBuffer) {
+    byteBuffer.put(this.byteBuffer);
+  }


Bug: Append Ignores Slice Boundaries

The appendTo method puts the entire byteBuffer into the target buffer, ignoring the offset and size() of this wrapper. When a ByteBufferWrappingBytes represents a slice (constructed with offset and length), this appends the wrong bytes. The method transfers from the buffer's current position/limit rather than the intended slice range defined by offset and size().

IMO it's not a bug

cursor · 2025-11-14T16:54:19Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Bytes32.java

+  private static final int SIZE = 32;
+
+  /** A {@code Bytes32} containing all zero bytes */
+  public static final Bytes ZERO = fromByte((byte) 0);


Bug: Type Mismatch: ZERO Constant Threatens Integrity

The ZERO constant is declared as type Bytes instead of Bytes32, causing a type inconsistency. The javadoc states it's a Bytes32 containing all zero bytes, but the actual type doesn't match. This breaks type safety and could cause issues when code expects a Bytes32 instance but receives a generic Bytes reference.

cursor · 2025-11-14T16:54:19Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Bytes48.java

+  public static final int SIZE = 48;
+
+  /** A {@code Bytes48} containing all zero bytes */
+  public static final Bytes ZERO = fromByte((byte) 0);


Bug: ZERO Constant: Type Inconsistency Threatens Safety

The ZERO constant is declared as type Bytes instead of Bytes48, causing a type inconsistency. The javadoc states it's a Bytes48 containing all zero bytes, but the actual type doesn't match. This breaks type safety and could cause issues when code expects a Bytes48 instance but receives a generic Bytes reference.

cursor · 2025-11-14T16:54:19Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/MutableBytes.java

+      byte[] newBytesArray = new byte[otherSize];
+      System.arraycopy(bytesArray, 0, newBytesArray, otherSize - size, size);
+      bytesArray = newBytesArray;
+      size = otherSize;


Bug: Immutability Contract Violated: Stale Hashcodes

The and, or, and xor methods mutate the size field after object construction when resizing the internal array. Since size is inherited from the immutable parent Bytes class and used for hashcode caching, this mutation breaks the immutability contract and can cause cached hashcodes to become stale, leading to incorrect behavior in hash-based collections.

lu-pinto · 2025-11-19T10:11:56Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Bytes.java

+   *
+   * @return The number of bytes this value represents.
+   */
+  public int size() {


make this final

cursor · 2025-11-20T17:03:39Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/DelegatingBytes.java

+    return delegate.trimLeadingZeros();
+  }
+
+  @Override


Bug: DelegatingBytes missing trimTrailingZeros override

The DelegatingBytes class overrides trimLeadingZeros() to delegate to its delegate (line 206-208), but is missing an override for trimTrailingZeros(). This means calls to trimTrailingZeros() will use the base Bytes implementation instead of delegating to the wrapped delegate, breaking the delegation pattern and potentially causing inconsistent behavior compared to other delegated methods.

This is a collapsed view of the previous old commits: * 0929d61 Merge remote-tracking branch 'upstream/main' into flatten-Bytes-class-hierarchy * | 6d79491 Miscelaneous fixes * | a4def2a Fix memleak in Hash and bug in devp2p Packet creation * | 10e6e81 fix bug in and/or/xor operations with UInt256/UInt384 * | 578e6bb Move bound checks for Bytes implementation out of constructors * | b9c6b05 Merge branch 'main' into flatten-Bytes-class-hierarchy * 4100d8b review feedback * afba2b9 change megamorphic benchmarks to slice and optimize size() * b2066fc JMH integration fixes * e40d796 remove InterfaceCall and VirtualCall benchmarks * dff599a fix ConnectTwoServersTest - missed package changes and port bindings * 5aba562 add missing package-info.java files * 1c641ff fix failure in DefaultDiscoveryV5ServiceTest about reusing ports * 279acd6 bring in old tuweni v1 after move * ace7910 move all other touched files to org.apache.tuweni.v2 package * 65f217b mv org.apache.tuweni.bytes.v2 to org.apache.tuweni.v2.bytes * ebaa8bd Implement Tuweni v2 Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

This is for easy reviewing by making the PR much shorter. Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

lu-pinto · 2025-11-27T17:00:17Z

I reverted changes made to other projects than bytes in order to make it more reviewable. Will issue separate PR's for other projects

cursor · 2025-11-27T17:03:40Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ByteBufferWrappingBytes.java

+  @Override
+  public void appendTo(ByteBuffer byteBuffer) {
+    byteBuffer.put(this.byteBuffer);
+  }


Bug: appendTo ignores offset and size in ByteBuffer wrapper

The appendTo(ByteBuffer) method in ByteBufferWrappingBytes ignores the offset and size fields, putting the entire source ByteBuffer instead of just the wrapped slice. All other methods in this class (like get, getInt, getLong, and, or, xor, equals, computeHashcode, toArray) correctly use offset + i when accessing data. However, appendTo just calls byteBuffer.put(this.byteBuffer) which will write from the source buffer's position to its limit, disregarding the stored offset entirely. This contrasts with BufferWrappingBytes and ByteBufWrappingBytes which slice their buffers in the constructor, and with ArrayWrappingBytes which correctly passes offset and size() to the put operation.

cursor · 2025-11-27T17:03:40Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ConstantBytesValue.java

+  @Override
+  public byte get(int i) {
+    return this.value;
+  }


Bug: ConstantBytesValue.get missing required bounds check

The get(int i) method in ConstantBytesValue returns the constant value without checking bounds, violating the documented contract of the abstract Bytes.get(int i) method which specifies it should throw IndexOutOfBoundsException if i < 0 or i >= size(). All other implementations (ArrayWrappingBytes, ConcatenatedBytes, etc.) either explicitly call checkElementIndex or rely on the underlying buffer to throw. This means Bytes.repeat((byte) 0, 5).get(100) would incorrectly return 0 instead of throwing an exception.

fab-10

first partial pass

fab-10 · 2025-11-28T13:54:56Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Utils.java

+    }
+  }
+
+  public static void checkElementIndex(int index, int size) {


could be rewritten using checkArgument like for checkLength with a formatted string highlighting the arugments

fab-10 · 2025-11-28T14:02:47Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/BytesValues.java

+
+  static final int MAX_UNSIGNED_SHORT = (1 << 16) - 1;
+  static final long MAX_UNSIGNED_INT = (1L << 32) - 1;
+  static final long MAX_UNSIGNED_LONG = Long.MAX_VALUE;


the name is misleading, because the value is max signed long.
Moreover, it is not used internally, so could be removed since not public

fab-10 · 2025-11-28T15:08:40Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ConstantBytesValue.java

+  @Override
+  public Bytes slice(int offset, int length) {
+    checkArgument(length >= 0, "Invalid negative length");
+    if (size() > 0) {


should we allow 0 sized constant bytes in the first place?

fab-10 · 2025-11-28T15:14:06Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ConstantBytesValue.java

+    if (this.size() != other.size()) {
+      return false;
+    }
+


IDK if it is worth to add another check that if the other is of the same type then just compare the single value

fab-10 · 2025-11-28T15:16:16Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ConstantBytesValue.java

+  @Override
+  protected int computeHashcode() {
+    int result = 1;
+    for (int i = 0; i < size(); i++) {


is there really the need to cycle to have a good hash code?

fab-10 · 2025-11-28T16:31:30Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ConcatenatedBytes.java

+      return EMPTY;
+    }
+    if (count == values.size()) {
+      return new ConcatenatedBytes(values.toArray(new Bytes[0]), totalSize);


using new Bytes[count] you can save one allocation

fab-10 · 2025-11-28T16:32:37Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ConcatenatedBytes.java

+    return new ConcatenatedBytes(concatenated, totalSize);
+  }
+
+  static Bytes create(List<Bytes> values) {


it seems there are no unit tests for this method

fab-10 · 2025-11-28T16:33:31Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ConstantBytesValue.java

+ * A Bytes value with just one constant value throughout. Ideal to avoid allocating large byte
+ * arrays filled with the same byte.
+ */
+class ConstantBytesValue extends Bytes {


no unit tests for this class

fab-10 · 2025-11-28T16:37:25Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/DelegatingBytes.java

+  }
+
+  @Override
+  public Bytes getImpl() {


should be package

fab-10 · 2025-11-28T16:52:42Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Bytes32.java

+    return new Bytes32(fromArray(bytes, offset));
+  }
+
+  public static Bytes fromArray(byte[] bytes, int offset) {


Should not this return a Bytes32?

Same for similar methods in the class

fab-10 · 2025-12-01T10:51:28Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Bytes48.java

+    return new Bytes48(fromByte(b));
+  }
+
+  public static Bytes fromByte(byte b) {


same as for Bytes32 should not these methos all return Bytes48?

fab-10 · 2025-12-01T11:06:13Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Bytes.java

+   * @param buffer The buffer to wrap.
+   * @return A {@link Bytes} value.
+   */
+  public static Bytes wrapBuffer(Buffer buffer) {


just wondering if it is cleaner to remove the type suffix for Buffer and ByteBuf variants and just always use wrap for all the following methods

fab-10 · 2025-12-01T11:11:10Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Bytes.java

+   * @return a value filled with a fixed byte
+   */
+  public static Bytes repeat(byte b, int size) {
+    return new ConstantBytesValue(b, size);


evaluate if size 0 makes sense

fab-10 · 2025-12-01T11:19:42Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Bytes.java

+    }
+  }
+
+  /**


why is the reason for this duplication?

fab-10 · 2025-12-01T11:27:20Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Bytes.java

+    return toFastHex(false);
+  }
+
+  public String toEllipsisHexString() {


fab-10 · 2025-12-01T11:37:07Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ByteBufWrappingBytes.java

+    this.byteBuf = byteBuf;
+  }
+
+  ByteBufWrappingBytes(ByteBuf byteBuf, int offset, int length) {


what about all the checks that are present in v1?

fab-10 · 2025-12-01T11:44:59Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/MutableBytes.java

+   * Create a new mutable bytes value.
+   *
+   * @param size The size of the returned value.
+   * @return A {@link MutableBytes} value.


we can say it is 0 filled

fab-10 · 2025-12-01T11:47:14Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/MutableBytes.java

+   */
+  public static MutableBytes fromArray(byte[] value) {
+    checkNotNull(value);
+    if (value.length == 0) {


curious of why this check here and non in the constructor

fab-10 · 2025-12-01T11:51:59Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/MutableBytes.java

+   * @return This mutable bytes instance.
+   */
+  public MutableBytes reverse() {
+    byte[] reverse = new byte[size];


reverse should be possible w/o allocating a new array

fab-10 · 2025-12-01T11:54:16Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Bytes.java

+ * A value made of bytes.
+ *
+ * <p>This class makes no thread-safety guarantee, and a {@link Bytes} value is generally not thread
+ * safe. However, specific implementations may be thread-safe, e.g., MutableBytes.


MutableBytes is not thread-safe, right?

github-actions · 2025-12-16T05:18:02Z

This PR was marked stale due to lack of activity. It will be closed in 14 days.

github-actions · 2025-12-31T05:23:05Z

Closed as inactive. Feel free to reopen if this PR is still being worked on.

cursor · 2026-01-07T09:33:45Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ConstantBytesValue.java

+  @Override
+  public byte get(int i) {
+    return this.value;
+  }


Missing bounds check in ConstantBytesValue.get() method

High Severity

The get(int i) method in ConstantBytesValue returns this.value for any index without validating that the index is within bounds. According to the Bytes.get() contract (which specifies @throws IndexOutOfBoundsException if i < 0 or i >= size()), invalid indices should throw an exception. Other implementations like ArrayWrappingBytes.get() correctly call checkElementIndex(i, size()) before returning. This bug allows silent access with any index value, which could mask errors in calling code.

cursor · 2026-01-07T09:33:45Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ByteBufferWrappingBytes.java

+  @Override
+  public byte get(int i) {
+    return byteBuffer.get(offset + i);
+  }


Missing bounds validation in ByteBufferWrappingBytes accessor methods

Medium Severity

The get(int i), getInt(int i), and getLong(int i) methods don't validate that the index is within the slice bounds (0 <= i < size()). They only rely on the underlying ByteBuffer bounds check which validates against the full buffer capacity, not the wrapper's offset and size. This allows reading data outside the intended slice when offset > 0. For example, with offset=10 and size=5, calling get(50) would access buffer position 60 instead of throwing. The getInt and getLong overrides also bypass the base class's bounds checking logic.

Additional Locations (2)

bytes/src/main/java/org/apache/tuweni/v2/bytes/ByteBufferWrappingBytes.java#L25-L29

bytes/src/main/java/org/apache/tuweni/v2/bytes/ByteBufferWrappingBytes.java#L30-L34

cursor · 2026-01-07T09:33:45Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ByteBufferWrappingBytes.java

+  @Override
+  public void appendTo(ByteBuffer byteBuffer) {
+    byteBuffer.put(this.byteBuffer);
+  }


ByteBufferWrappingBytes.appendTo ignores offset and size

Medium Severity

The appendTo(ByteBuffer) method uses byteBuffer.put(this.byteBuffer) which reads from the source buffer's position() to limit(), completely ignoring the wrapper's offset and size() fields. When wrapping a slice (where offset != 0 or size() != buffer.limit()), this will write incorrect bytes. Compare with ArrayWrappingBytes.appendTo() which correctly calls byteBuffer.put(bytes, offset, size()) to respect the slice boundaries.

cursor · 2026-01-07T09:33:45Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/Bytes.java

+   */
+  public static Bytes repeat(byte b, int size) {
+    return new ConstantBytesValue(b, size);
+  }


Missing negative size validation in Bytes.repeat factory method

Medium Severity

The Bytes.repeat(byte b, int size) method creates a ConstantBytesValue without validating that size is non-negative. Other factory methods like wrap, wrapBuffer, wrapByteBuf, and wrapByteBuffer all include checkArgument(size >= 0, "Invalid negative length"). Calling Bytes.repeat((byte)0, -1) creates an object with size() == -1, which leads to incorrect behavior: isZero() returns true without checking any bytes, isEmpty() returns false, and toArrayUnsafe() throws NegativeArraySizeException. This creates an invalid object state that causes confusing errors downstream.

cursor · 2026-01-07T09:33:45Z

bytes/src/main/java/org/apache/tuweni/v2/bytes/ConcatenatedBytes.java

+    int totalSize = 0;
+
+    for (Bytes value : values) {
+      int size = value.size();


Inconsistent null handling between wrap method overloads

Medium Severity

The ConcatenatedBytes.create(List<Bytes>) method calls value.size() on line 84 without checking if value is null, causing NPE for lists containing null elements. However, the varargs overload create(Bytes...) explicitly handles nulls by checking if (value == null) { continue; } on lines 33-36. This inconsistency means Bytes.wrap(List<Bytes>) crashes with null elements while Bytes.wrap(Bytes...) handles them gracefully. Users could encounter unexpected NPEs when using the List-based API.

github-actions bot added a commit that referenced this pull request Mar 4, 2025

@lu-pinto has signed the CLA in #40

5e70cbe

lu-pinto force-pushed the flatten-Bytes-class-hierarchy branch 2 times, most recently from 81cb3e2 to 46f5de9 Compare March 6, 2025 13:33

lu-pinto force-pushed the flatten-Bytes-class-hierarchy branch from 0625d27 to 2dbda56 Compare March 12, 2025 16:36

lu-pinto closed this Apr 4, 2025

lu-pinto reopened this Apr 4, 2025

github-actions bot locked and limited conversation to collaborators Apr 4, 2025

lu-pinto marked this pull request as draft April 8, 2025 15:23

lu-pinto force-pushed the flatten-Bytes-class-hierarchy branch from 1b4e159 to 8a24b0e Compare May 21, 2025 12:54

lu-pinto force-pushed the flatten-Bytes-class-hierarchy branch from 8a24b0e to 1c641ff Compare May 22, 2025 12:49

lu-pinto marked this pull request as ready for review May 22, 2025 13:25

Consensys unlocked this conversation May 22, 2025

lu-pinto force-pushed the flatten-Bytes-class-hierarchy branch 2 times, most recently from cc29c50 to dff599a Compare May 22, 2025 13:43

lu-pinto mentioned this pull request May 22, 2025

Adopt new Tuweni API changes Consensys/discovery#192

Draft

macfarla reviewed Jun 3, 2025

View reviewed changes

bytes/src/jmh/java/org/benchmark/VirtualCall.java Outdated Show resolved Hide resolved

bytes/src/main/java/org/apache/tuweni/v2/bytes/ArrayWrappingBytes.java Outdated Show resolved Hide resolved

bytes/src/test/java/org/apache/tuweni/bytes/ConcatenatedBytesTest.java Show resolved Hide resolved

ahamlat reviewed Jun 3, 2025

View reviewed changes

github-actions bot added the Stale label Jun 18, 2025

siladu removed the Stale label Jun 23, 2025

ahamlat reviewed Jun 23, 2025

View reviewed changes

github-actions bot closed this Oct 23, 2025

macfarla reopened this Oct 30, 2025

macfarla removed the Stale label Oct 30, 2025

cursor bot reviewed Oct 30, 2025

View reviewed changes

github-actions bot added the Stale label Nov 13, 2025

cursor bot reviewed Nov 13, 2025

View reviewed changes

lu-pinto mentioned this pull request Nov 13, 2025

Potential native libsodium memory leakage in Tuweni Crypto #42

Open

lu-pinto force-pushed the flatten-Bytes-class-hierarchy branch from ad67e19 to a4def2a Compare November 13, 2025 14:31

github-actions bot removed the Stale label Nov 14, 2025

cursor bot reviewed Nov 14, 2025

View reviewed changes

lu-pinto commented Nov 19, 2025

View reviewed changes

cursor bot reviewed Nov 20, 2025

View reviewed changes

lu-pinto added 3 commits November 27, 2025 16:44

Make MutableBytes inherit from ArrayWrappingBytes

9749096

Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

revert changes to any other projects than not bytes

a646271

This is for easy reviewing by making the PR much shorter. Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

lu-pinto force-pushed the flatten-Bytes-class-hierarchy branch from cddbcca to a646271 Compare November 27, 2025 16:58

cursor bot reviewed Nov 27, 2025

View reviewed changes

lu-pinto mentioned this pull request Nov 27, 2025

Changes to io project to accomodate bytes v2 #53

Draft

fab-10 reviewed Nov 28, 2025

View reviewed changes

fab-10 reviewed Dec 1, 2025

View reviewed changes

github-actions bot added the Stale label Dec 16, 2025

github-actions bot closed this Dec 31, 2025

lu-pinto reopened this Jan 7, 2026

lu-pinto removed the Stale label Jan 7, 2026

cursor bot reviewed Jan 7, 2026

View reviewed changes

+                  }
+                }
+                /**

Conversation

lu-pinto commented Mar 4, 2025 • edited by cursor bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR description

Uh oh!

github-actions bot commented Mar 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lu-pinto commented Mar 4, 2025

Uh oh!

lu-pinto commented Mar 4, 2025

Uh oh!

lu-pinto commented May 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lu-pinto commented May 22, 2025

Uh oh!

macfarla left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Jun 18, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lu-pinto Aug 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ahamlat commented Jun 23, 2025

Uh oh!

Choose a reason for hiding this comment

lu-pinto commented Mar 4, 2025 •

edited by cursor bot

Loading

github-actions bot commented Mar 4, 2025 •

edited

Loading

lu-pinto commented May 21, 2025 •

edited

Loading

lu-pinto Aug 8, 2025 •

edited

Loading