On 11/11/09 8:49 AM, "Justin Santa Barbara" <[email protected]> wrote:
> Caching the protocol seems a better approach than mine. I did notice that
> the Protocol was being reconstructed using reflection (and there seem to be
> a few bugs around it, e.g. Avro-171), so was thinking that maybe this
> should be done. Happy that you did it for me!
>
> What about Philip's point on existing Hadoop interfaces? Any plans for how
> we'll generate the Protocol object for these?
>
> Justin
Maybe Annotation Mix-ins are useful here? You could define all the
necessary bits to connect an existing set of classes/interfaces and not
modify any of the original classes:
http://wiki.fasterxml.com/JacksonMixInAnnotations
I'm not familiar enough with the Avro implementation yet to know if I'm way
off on this however...
>
>
>
>
> On Wed, Nov 11, 2009 at 8:42 AM, Doug Cutting <[email protected]> wrote:
>
>> Justin Santa Barbara wrote:
>>
>>> @SuppressWarnings("all")
>>> public interface BulkData {
>>> ByteBuffer read() throws AvroRemoteException;
>>> Void write(@Named("data") ByteBuffer data) throws AvroRemoteException;
>>> }
>>>
>>
>> I've taken a different approach in AVRO-185.
>>
>> https://issues.apache.org/jira/browse/AVRO-185
>>
>> There I simply added the protocol to the generated interface, so reflection
>> need no longer be used to determine the method list, nor method parameter
>> names.
>>
>>
>> I'm guessing there's some historical reason here - can anyone fill me in
>>> on
>>> the reasoning?
>>>
>>
>> The historic reason is that reflect was implemented before specific, and
>> specific was built to depend on reflect. Reflect already had a means to get
>> the method list (including parameter names) from an interface, so none was
>> added for specific.
>>
>> Doug
>>
>
