implementations from these to SpecificData. One can imagine also
maps via the java-class schema property with specific data. The
introspection. That's not the case here, rather this is just
> I agree with the SpecificCompiler#getStringType() change. I actually have an
> early draft patch that has this change. As for using the ReflectDatum
> Reader/Writer, I guess that might be sufficient for some use cases but,
> unfortunately, it isn't for mine ;). We're using kiji
> (
https://github.com/kijiproject) and I don't have control over the
> Reader/Writer implementation being used.
>
> I don't want to dirty the Generic/Specific reader/writers but it might be
> some desirable feature to support JDK classes like the
> BigDecimal/BigInteger?
>
> --
> Alex
>
> On Thursday, February 28, 2013 at 10:04 AM, Doug Cutting wrote:
>
> You could get the specific compiler to emit the desired type by
> modifying the method SpecificCompiler#getStringType() to take the
> Schema as a parameter and, if it has a java-class attribute, return
> that. Then things should work so long as you use ReflectDatumReader
> and ReflectDatumWriter. Would that suffice?
>
> Doug
>
> On Thu, Feb 28, 2013 at 9:25 AM, Alexandre Normand
> <
[hidden email]> wrote:
>
> Hey Doug,
> I was also wondering about something related. In reflection, we can use the
> java-class property to define the java class for stringable types. Could we
> find a way to bring some of this to the Specific generated classes so that a
> stringable type (I'm specifically thinking of BigDecimal and BigInteger)
> could be exposed as the java-class type instead of Strings? I started
> looking into this and there seem to be two possibilities, none of which I'm
> terribly excited about:
>
> 1. Use some reflection to invoke the string constructor for the
> java-class…but that seems dirty as the Specific API probably shouldn't do
> reflection, right?
> 2. Handle a very specific list of java-class types (such as BigDecimal and
> BigInteger) and have code that deals specifically with these in
> Reader/Writer.
>
> Thoughts?
> --
> Alex
>
> On Thursday, February 28, 2013 at 9:19 AM, Doug Cutting wrote:
>
> Annotation names in IDL are copied directly to schema properties with
> the same names.
>
> The bug is in the IDL documentation, which uses the annotation
> @java_class in an example, which is meaningless. The Java
> implementation requires the "java-class" schema property, so the
> annotation used should be @java-class.
>
> I filed an issue in Jira for this.
>
>
https://issues.apache.org/jira/browse/AVRO-1264>
> Doug
>
> On Wed, Feb 27, 2013 at 7:18 PM, avronewbie <
[hidden email]> wrote:
>
> For the IDL field:
>
> @java_class("java.util.ArrayList") array<int> arrayOfInts;
>
> the JSON schema generated by the avro-maven-plugin is
>
> {\"name\":\"arrayOfInts\",\"type\":{\"type\":\"array\",\"items\":\"int\",\"java_class\":\"java.util.ArrayList\"}}
>
> Shouldn't it be generated in JSON as java-class (with hypen instead of
> underscore) instead of java_class? Because of this reading from avro file is
> not working.
>
>
>
>
> --
> View this message in context:
>
http://apache-avro.679487.n3.nabble.com/Incorrect-Json-schema-generated-for-java-class-tp4026430.html> Sent from the Avro - Users mailing list archive at Nabble.com.
>
>
Locked
