avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Santa Barbara <jus...@fathomdb.com>
Subject Re: Why Paranamer?
Date Wed, 11 Nov 2009 16:49:44 GMT
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




On Wed, Nov 11, 2009 at 8:42 AM, Doug Cutting <cutting@apache.org> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message