You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current JavaBeanSchema and JavaFieldSchema do not support working with Java 14 records by default because the record components are private final and the accessor methods do not conform to the Java bean convention (field() instead of getField()).
A new schema class for the schema coder could be created to support coding Java 14 records. Java records are especially well suited as intermediate data structures in beam pipelines because of their automatically generated hash, equals, and toString methods as well as their immutability. This would reduce boilerplate which inevitably causes issues down the line as everyone reimplements the same methods with varying degrees of correctness and uses code generation tools with poorly documented semantics.
Issue Priority
Priority: 3 (nice-to-have improvement)
Issue Components
Component: Python SDK
Component: Java SDK
Component: Go SDK
Component: Typescript SDK
Component: IO connector
Component: Beam examples
Component: Beam playground
Component: Beam katas
Component: Website
Component: Spark Runner
Component: Flink Runner
Component: Samza Runner
Component: Twister2 Runner
Component: Hazelcast Jet Runner
Component: Google Cloud Dataflow Runner
The text was updated successfully, but these errors were encountered:
I just wanted to mention that all Java Beam artifacts are still built with Java 8. So I'm not sure that it's possible to do until Beam will move to Java 14.
What would you like to happen?
The current
JavaBeanSchema
andJavaFieldSchema
do not support working with Java 14 records by default because the record components areprivate final
and the accessor methods do not conform to the Java bean convention (field()
instead ofgetField()
).A new schema class for the schema coder could be created to support coding Java 14 records. Java records are especially well suited as intermediate data structures in beam pipelines because of their automatically generated
hash
,equals
, andtoString
methods as well as their immutability. This would reduce boilerplate which inevitably causes issues down the line as everyone reimplements the same methods with varying degrees of correctness and uses code generation tools with poorly documented semantics.Issue Priority
Priority: 3 (nice-to-have improvement)
Issue Components
The text was updated successfully, but these errors were encountered: