Replace cglib with annotation processing

[brianm]

The use of cglib for code generation is increasingly causing problems with Java versions. Using an annotation processor to generate the classes instead of using runtime byte code generation seems like a more future-proof approach, and would help would help with debug-ability.

I propose keeping config-magic as a single jar, using an annotation processor in said jar to pick up config objects, and splatting out nice .java definitions using java-poet. This would ad java-poet as a compile time dependency, but not as a runtime dependency.

Any feeling?

[brianm]

CC: @divyekapoor as I know you have been bitten by cglib usage here in the past.

[john9x]

Hi @brianm !
Maybe this will be interesting for you - in my fork I replaced cglib with ByteBuddy to get rid of problems with Java 16+. If you want I can provide pull request.

[divyekapoor]

I am ambivalent - the current approach seems to be working well for us (with the exception of config documentation - we would really like that feature automated, we have manual docs right now and they're pretty painful).

Some context on our uses:
The .jar we're using this library most heavily on is about 1.2G in size - the annotation processor will take some time if it runs through all the classes in the .jar (slowing down builds). We are also explicitly on Java 8 Adopt OpenJDK. I'm not sure when we'll upgrade to a newer version (but it's a while away). Right now, there are no issues that I'm aware of with cglib.

In order to avoid pre-optimizing, we can see how it goes if there's a test jar I can play with and report back on the compile time impact.