sealed traitAmqpFieldValue extends Product with Serializable
This hierarchy is meant to reflect the output of
com.rabbitmq.client.impl.ValueReader.readFieldValue in a type-safe
way.
Note that we don't include LongString here because of some ambiguity in
how RabbitMQ's Java client deals with it. While it will happily write out
LongStrings and Strings separately, when reading it will always interpret
a String as a LongString and so will never return a normal String.
This means that if we included separate LongStringVal and StringVals we
could have encode-decode round-trip differences (taking a String sending
it off to RabbitMQ and reading it back will result in a LongString).
We therefore collapse both LongStrings and Strings into a single StringVal
backed by an ordinary String.
Note that this type hierarchy is NOT exactly identical to the AMQP 0-9-1
spec. This is partially because RabbitMQ does not exactly follow the spec
itself (see https://www.rabbitmq.com/amqp-0-9-1-errata.html#section_3)
and also because the underlying Java client chooses to try to map the
RabbitMQ types into Java primitive types when possible, collapsing a lot
of the signed and unsigned types because Java does not have the signed
and unsigned equivalents.
Linear Supertypes
Serializable, Serializable, Product, Equals, AnyRef, Any
This hierarchy is meant to reflect the output of com.rabbitmq.client.impl.ValueReader.readFieldValue in a type-safe way.
Note that we don't include LongString here because of some ambiguity in how RabbitMQ's Java client deals with it. While it will happily write out LongStrings and Strings separately, when reading it will always interpret a String as a LongString and so will never return a normal String. This means that if we included separate LongStringVal and StringVals we could have encode-decode round-trip differences (taking a String sending it off to RabbitMQ and reading it back will result in a LongString). We therefore collapse both LongStrings and Strings into a single StringVal backed by an ordinary String.
Note that this type hierarchy is NOT exactly identical to the AMQP 0-9-1 spec. This is partially because RabbitMQ does not exactly follow the spec itself (see https://www.rabbitmq.com/amqp-0-9-1-errata.html#section_3) and also because the underlying Java client chooses to try to map the RabbitMQ types into Java primitive types when possible, collapsing a lot of the signed and unsigned types because Java does not have the signed and unsigned equivalents.