Static type constraints in languages like Java present challenges with the multi-typed value field in the Telemetry JSON schema. The schema's current state, which is aligned with JSON Schema Draft-07, is incompatible with Java code generators that expect a singular type for any given field.
Problem Description
The value field within the payloads array is intended to support multiple types (number, boolean, string) to allow for versatile telemetry data representation. This multi-type pattern is not natively supported by Java code generation tools, which often results in faulty generation or complete failure due to the static typing requirement.
In Kotlin, similar issues are gracefully managed using sealed classes. However, Java does not have an equivalent feature set, leading to code generation issues.
Proposed Change
To address the limitation, we propose the following adjustments to the schema:
Redefine the value field to a generic object type in the schema.
Document the intended types (number, boolean, string) within the value field's description to inform developers of the expected types.
Expected Benefits
Ensures successful code generation for Java and similar statically typed languages.
Maintains a single schema for use across multiple languages and tools.
Adjusted Schema Snippet
"value": {
"description": "The value is expected to be a number, boolean, or string."
}
Issue Summary
Static type constraints in languages like Java present challenges with the multi-typed
valuefield in the Telemetry JSON schema. The schema's current state, which is aligned with JSON Schema Draft-07, is incompatible with Java code generators that expect a singular type for any given field.Problem Description
The
valuefield within thepayloadsarray is intended to support multiple types (number, boolean, string) to allow for versatile telemetry data representation. This multi-type pattern is not natively supported by Java code generation tools, which often results in faulty generation or complete failure due to the static typing requirement.In Kotlin, similar issues are gracefully managed using sealed classes. However, Java does not have an equivalent feature set, leading to code generation issues.
Proposed Change
To address the limitation, we propose the following adjustments to the schema:
valuefield to a genericobjecttype in the schema.valuefield's description to inform developers of the expected types.Expected Benefits
Adjusted Schema Snippet