Add Ability to Generate Java Bean from an Interface

Given the following interface I would like to be able to generate a bean with minimal effort using ByeBuddy. Ideally, I would like to simply give ByteBuddy an interface with getter and setter pairs and have it take care of doing the analysis on the interface and create a dynamic java bean.

public interface UserConfig {

    String getName();

    void setName(String name);

    int getAge();

    void setAge(int age);

}

[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?

[Flamenco]

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