[
https://issues.apache.org/jira/browse/AVRO-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776577#action_12776577
]
Doug Cutting commented on AVRO-185:
-----------------------------------
> (space = c.getEnclosingClass().getName() + "$"); That looked like new code;
> is there a small test with nested classes?
That is not new code. And yes, TestReflect tests nested classes.
> I'm confused why SpecificData.createSchema() uses reflection to generate the
> schema.
Hmm. That javadoc should certainly remain in ReflectData. This method
constructs entries for a cache from class->schema. At issue is whether you
should be able to use GenericArray<Foo> as a top-level type, e.g., in a file,
where Foo is defined by a SpecificRecord. If so, then
SpecificData#createSchema() should support more than records and must use
reflection for maps and arrays. That said, the logic copied from ReflectData
currently handles some cases that the specific compiler doesn't generate, e.g.,
nested classes. And enum and fixed schemas are still created with reflection,
when these should use the schema from the generated code.
> before this patch, there were two implementations of createSchema(), and
> there's only one left. Was that intentional?
Before SpecificData overrode ReflectData#createSchema() for the case of
records. After, the record-specific logic is refactored to
createRecordSchema() and ReflectData overrides that.
Perhaps I should replace this with createNamedSchema to handle records, enums
and fixed, which differ between specific and reflect. I can also move the
nested-class logic to reflect, plus fix the javadoc.
> Should you also update the build.xml to remove the paranamer compilation step?
Yes, good catch. We still need to run it for reflect tests, but not for
generated code. Frankly, I can't now see where it's currently run on reflect
tests... Hmm.
> specific should not depend on reflect
> -------------------------------------
>
> Key: AVRO-185
> URL: https://issues.apache.org/jira/browse/AVRO-185
> Project: Avro
> Issue Type: Improvement
> Components: java
> Reporter: Doug Cutting
> Assignee: Doug Cutting
> Fix For: 1.3.0
>
> Attachments: AVRO-185.patch
>
>
> Currently the specific implementation inherits from the reflect
> implementation. To fix AVRO-80, this dependency should be reversed, since
> specific will still share all data representations but records and enums with
> generic, but specific and reflect will no longer use common representations
> for strings and arrays.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
