Hi Justin, I very much agree that it would be great to get rid of the paranamer build step for the generated code.
> Given some of the complexities involved in paranamer builds, I'm wondering > why Avro doesn't use annotations instead. It seems that parameter names are > only needed for Avro interfaces, and these are mostly generated from .avpr > files (rather than being hand-written). For the generated code, there's a ticket (http://issues.apache.org/jira/browse/AVRO-164) to generate the paranamer data as part of the code-generation, instead of needing a paranamer build step. > I'm guessing there's some historical reason here - can anyone fill me in on > the reasoning? I believe that the goal is to replace seamlessly how Hadoop handles RPCs; that's done using reflection on existing interfaces (instead of generating code from an .avpr file). It's not practical to go back and annotate each parameter in the existing code. "Void write(@Named("data") ByteBuffer data)" may be fine in generated code, but it's a bit messy in normal code. I like your implementation, and using annotations has a certain elegance. It'd be nice not to have two different code paths for figuring out the parameters (though it wouldn't be the worst thing in the world). What do you think of the approach in AVRO-164, which would be to simply generate the public static final String (or is it String[]--don't remember) that Paranamer uses? Cheers, -- Philip
