I'm a bit confused of the "status" of the ReflectDatumReader and
ReflectDatumWriter classes. We use them to transparently serialise and
deserialise JavaBeans-like objects. We automatically get an instance of
the expected class back and do not need to write any conditional code
based on what the schema is. Perfect in our Java world, and just what
reflection is for.
Now if I look at the package doc for org.apache.avro.reflect I see this:
"This API is not recommended except as a stepping stone for systems that
currently uses Java interfaces to define RPC protocols. For new RPC
systems, the |specific|
<http://avro.apache.org/docs/1.7.0/api/java/org/apache/avro/specific/package-summary.html>
API is preferred. For systems that process dynamic data, the |generic|
<http://avro.apache.org/docs/1.7.0/api/java/org/apache/avro/generic/package-summary.html>
API is probably best."
What I'm confused by is the assertion that the generic API is "probably
best" for processing dynamic data.
However, I can see no automatic, transparent way of using the generic
readers and writers to serialise a JavaBean and then deserialise the
stream into an instance of that JavaBean -- automatically. Writing
conditional code and playing around with field names is not an answer.
Am I missing something, or should your assertion be weakened?
Peter
