byte-buddy-dep: Switch from Lombok to Google Auto-Value

[wltjr]

Initial pull request, need to update pom.xml and related for build. Build will likley fail otherwise.

Fixes issue #397

Switches all imports and annotations. Drops lombok annotation arguments,
as those are not used in Auto-Value.

for f in $(grep -l -m1 lombok\\.EqualsAndHashCode -r *); do
    sed -i -e "s|lombok.EqualsAndHashCode|com.google.auto.value.AutoValue|" \
        -e "s|@EqualsAndHashCode.*|@AutoValue|g" "${f}"
done

[wltjr]

Initial attempt to update build system. Added to global pom.xml like the others lombok and findbugs. Not dropping lombok, since it maybe used in other parts I did not update. I can update those if needed. At this time I only care about byte-buddy-dep.

Also findbugs can likely be updated to spotbugs, the successor.

[wltjr]

For Java 9+ build likely need to add

javac -processor com.google.auto.value.processor.AutoAnnotationProcessor

I have not had any luck with

  --processor-module-path <path>
        Specify a module path where to find annotation processors
  --processor-path <path>, -processorpath <path>
        Specify where to find annotation processors
  --source-path <path>, -sourcepath <path>
        Specify where to find input source files

[wltjr]

Tried to fix tests/build without luck. Seems the auto stuff is >= Java 1.8, so will not work on 6 or 7 due to class issues. Unless another is made with an older bytecode, and uploaded to Maven. The error One @AutoValue class may not extend another I cannot explain as I do not see that and it compiles fine for me. But I am not using maven, just straight javac. Adding annotation processors to compiler plugin seems to break build of other stuff. Maybe need to add other processors or break those into individual project pom.xml.

[raphw]

As you say, this will unfortunately not work out since AutoValue requires Java 8 and at this point, I need to support Java 6 and before. For Java 9 and 10, Byte Buddy works, only building it is problematic at this point while it is perfectly possible.

I just updated Lombok. Does this help you out?

[wltjr]

@raphw no worries, I have it for my needs, and at least it was explored as a potential for the future. The other thing maybe to use something to inject the annotations import and annotation to the various classes as part of build based on jdk version. Fair amount of things generate Java code, so could be another option. I may play around with the build if you are open to that approach.

byte-buddy-dep itself seems good to go for Java 9+. I haven't built or tested under 10 yet, but no issues under 9. The issue was in building it, as I have to build dependencies. Some opt to use binaries in that process. Short of bootstrapping things like javacc, antlr, and others. I build everything from source including deps. Thus to build byte-buddy-dep I need to be able to build lombok.

Lombok presently cannot build under Java 9. I have modified Lombok heavily for building under Java 9. Basically dropping stuff for < 9 because it does not build under 9. Down to just 1 issue which I have filed with Lombok. Though I am not sure when that will be addressed. It seems rather odd, and I assume not so trivial to fix. I wasted more time on that one aspect than I did with switching byte-buddy-dep to autovalue.

byte-buddy-dep is the only package I have come across thus far that uses lombok. It seems rather troublesome for a few reasons as follows;

1. Number of dependenies to build Lombok, ~70 eclipse libraries (Issue Please consider dropping lombok for other library #397)
2. Issues building under various JDKs due to how its coupling with them and into the compiler. I had to fix at first for 1.8, not just 9
3. Circular deps
4. Number of open bugs, seems pretty high
5. Uses dead? old packages itself to build...

The idea behind Lombok is interesting and nothing against its authors. Its codebase seems interesting and most issues are a result of supporting a range of JDK versions. It is my least favorite package, and spent a considerable time on just that not only in dependencies but its own build issues.

The only reason I ever needed it was for byte-buddy-dep. A dep of hibernate-core I haven't finished packaging. Then a blocker for my Netbeans 9 packaging as it is also a dep. But since switching byte-buddy-dep to AutoValue, I was able to proceed with Netbeans 9

I am good for my needs now. Though going forward maybe interesting for Lombok and Java 9+. Thus when ever you get around to that maybe time to switch from that to AutoValue or other. Grabbing a pre-built binary to use from Maven or Gradle jar repo is very different to building everything from source with all being a given source/target/release. Like the Auto* being >=1.8. Those jars I build as 9, under 9, so newer than grabbed from Maven/Gradle. The entire stack is that way. I need to update a fair amount of packages from --release 8 to 9. That is another longer term issue requiring other changes not relevant here.