Primitive types for nullable fields

[tomas0svk]

Optional attributes of various types use primitive type (e.g. int, double) together with jakarta.@nullable annotations.

• annotation is meaningless
• default value (0) is transmitted, so consumer cannot distinguish between not_set and literal 0.

Additionally, price* aiitributes use String, while BigDecimal would be far more reasonable and safer for client.

For instance BaseBet

    /**
     * The current price of the bet.
     * This can be {@code null} if not set.
     */
    @Nullable public String price;

    /**
     * The probability of the bet.
     */
    @Nullable public double probability;

    /**
     * The participant ID associated with the bet.
     */
    @Nullable public int participantId;

    /**
     * The player ID associated with the bet.
     */
    @Nullable public int playerId;

[shirbenishay]

Thank you for your feedback regarding nullable primitives and the use of String for price attributes.

We understand the concerns raised, especially around distinguishing null from default primitive values and around the use of String instead of BigDecimal.

1. Nullable primitives (int, double)
   While it’s true that Java primitives cannot hold null and default to 0 / 0.0, the @nullable annotation in this context serves as a contract-level indicator rather than a runtime guarantee.
   Our API model is aligned with the serialized message format. At the transport level (JSON), field presence or absence is handled by the serialization layer. Changing primitives to wrapper types (Integer, Double) would introduce breaking changes to:
   The published schema
   Generated client SDKs
   Existing integrations relying on the current contract
   Since backward compatibility is critical for our consumers, we are not planning to introduce such breaking changes at this stage.

2. Use of String for price attributes-
   Price fields are represented as String intentionally because this is the exact format in which values are transmitted to customers via RabbitMQ.
   The model reflects the transport contract, not an internal computation model. Specifically:
   We send prices as strings in the message payload.
   We must preserve the exact representation (including formatting and scale).
   The class mirrors the message structure one-to-one.

[tomas0svk]

Just to be sure ... is this developed as a freelance project or as a part of paid lsports feed service?

1. yes, I understand that it is not easy to fix bad design later. However if you specify "contract-level indicator" of nullability, clients need to understand that the field is nullable, store it in nullable field and implement weird logic, that in fact 0 means null. So it would be no big deal for anyone.
2. If "is the exact format in which values are transmitted to customers", i would add, that it is not, the real format is byte array in Body of TCP Packets. Purpose of SDK is to add abstraction level over raw data.