Add Ability to Generate Java Bean from an Interface about byte-buddy

[raphw]

Implementing the methods is quite easy as you can use the FileAccessor.ofBeanProperty() interception. However, you would still need to define the fields. With Byte Buddy, you would therefore define a bean as follows:

new ByteBuddy()
  .subclass(UserConfig.class)
  .method(isGetter().or(isSetter())).intercept(FieldAccessor.ofBeanProperty())
  .defineField("name", String.class, Visibility.PRIVATE)
  .defineField("age", int.class, Visibility.PRIVATE)
  .make()

I take it that you want Byte Buddy to generate the fields for you? While I understand that this is convenient, I feel that it is somewhat out of scope for the library as one can easily write a custom adapter. For example:

<T> DynamicType.Builder<T> fields(DynamicType.Builder<T> builder, Class<?> type) {
  for(Method method : type.getDeclaredMethods()) {
    if(method.getName().startsWith("set") {
      String name = method.getName().substring(3, 4).toLowerCase() + method.getName().substring(4);
      builder = builder.defineField(name, method.getParameterTypes()[0], Visibility.PRIVATE);
    }
  }
  return builder;
}

This way, one could for example also add annotations, custom visibility, custom names, different field mappings, etc. If Byte Buddy did all this automatically, it would take this freedom away. In Java 8, the above code can even be expressed as a one liner.

I would recommend you to hide this away in an adapter or even by subclassing Byte Buddy and overriding the subclass method and everything is done under the covers. Would this be a solution for you?

[saden1]

That's pretty much what I am doing. I only ask that bytebuddy provide such functionally because it seems like a common usecase. Perhaps bytebuddy should provide utility classes for common usescases so people don't have have to reinvent the wheel.

[raphw]

I will give it some thought. I do not want to bloat the library with too many common use cases as this caused quite some trouble with cglib where something similar was attempted. But I see the use of it.

[saden1]

I appreciate that.

[raphw]

I decided against an explicit API. From my experience with cglib, this can be better solved by an external library which is specialized in handling exceptions. However, I decided to add some convenience methods to make adding methods from reflection results more easy. I hope you can live with this compromise.

Thank you again for using Byte Buddy and your feedback!

[Flamenco]

Thanks for the example above, @raphw. You might want to rename toLowerClase to toLowerCase though.