1

I recently moved to JDK 17 from JDK 11 which triggered an update to the Chronicle Wire library. We used to use version 2.17.50 with JDK 11 and now we have moved to chronicle-wire version 2.22.17 and chronicle-bytes version 2.22.21.

Following code used to work fine with JDK 11 but not with JDK 17. It seems the release method is deprecated.

public static Object deserializeFromBinary(final byte[] rawBytes, final Class<?> classVal, final String bookmark) 
{
   Bytes<?> bytesDeserialize = Bytes.allocateDirect(rawBytes);
   Wire wire = new BinaryWire(bytesDeserialize);
   try {
       return wire.read(() -> bookmark).object(classVal);
   } finally {
       bytesDeserialize.release();
   }
}

How can we release native bytes now? Anyone has come across the same situation?

ATO
  • 574
  • 4
  • 14
  • 1
    … and this `release()` method has no documentation? Does this class implement `Closeable`, so that you can write `try(Bytes> bytesDeserialize = Bytes.allocateDirect(rawBytes)) { return new BinaryWire(bytesDeserialize).read(() -> bookmark).object(classVal); }` instead of calling `release()` manually? – Holger Apr 06 '22 at 14:46
  • @Holger direct Bytes use a reference count or trace reference owners for more complex life cycles so the try-with-resource isn't ideal in this case. – Peter Lawrey Apr 06 '22 at 15:42
  • 1
    @PeterLawrey the object is allocated at the beginning of the method and released at the end of the method, so why should try-with-resource not be ideal *in this case*? Why should it matter what this class does “for more complex life cycles” when this obviously isn’t a complex life cycle? – Holger Apr 06 '22 at 15:47
  • @Holger We have a component that supports both Closeable and reference tracing and the life cycle is very complicated. While it can be done it's horrible to test. Note: the deserialization of the object can result in an increase in the reference count so it's not as simple as discarding it after it is "closed" – Peter Lawrey Apr 08 '22 at 09:17
  • 1
    @PeterLawrey sorry for being ignorant, but I only care about the OP’s case as described in the question and don’t see why the simple solution to OP’s described case should be inappropriate just because there is some other complicated case somewhere. I do not even understand what you are suggesting as alternative (in your “complicated” case, not the simple answer you’ve posted). The `release()` method seems to be designed to decrement the reference count you’ve mentioned, but it has been marked deprecated, so what’s the alternative (besides not using a complicated life cycle at all)? – Holger Apr 08 '22 at 09:28
  • @Holger Previously, there was a reserve() and release() method. However, this was error-prone so the API was altered to support reserve(ResourceOwner) and release(ResourceOwner) so the library could detect either double reserve, discarding without releasing, or release something not reserved. The old release() method was deprecated to give people time to migrate. However, in the OP's case, it's all for nothing as there is a byte[] provided by the user, so it doesn't need to be managed and released deterministically as it can be wrapped with Bytes.wrap(rawBytes) and there is nothing to be done. – Peter Lawrey Apr 08 '22 at 10:23

1 Answers1

0

This resource, in its simplest form, has a reference counter. In more complex scenarios, it tracks owners of the Bytes to ensure the same owner doesn't reserve or release twice.

As you don't need owners, you can use releaseLast() how even simpler than that you don't need to allocate direct memory.

In this example, the Bytes use an on-heap byte[] so don't need to be released.

public static Object deserializeFromBinary(final byte[] rawBytes, final Class<?> classVal, final String bookmark) {
    return WireType.BINARY_LIGHT.apply(Bytes.wrapForRead(rawBytes))
            .read(bookmark)
            .object(classVal);
}

The WireType.BINARY_LIGHT turns off some expensive options you probably don't need.

Ideally, you shouldn't be creating byte[] or new Wire on each object if this is called often.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130