Please consider dropping lombok for other library

[wltjr]

Lombok is a complete mess, horrible library! It requires a good deal of eclipse to build. I had to package some 70+ packages to build Lombok from source. It has further issues with Java 9. I think having byte-buddy depend on and using lombok is not a good ideal. It has way to many dependencies. Lombok seems to be widely in use in byte-buddy-dep.

Now as part of building Netbeans 9 from source. I need byte-buddy-dep. Which now I have to get lombok building under Java 9, and running into issues there. Seems way excessive to have 70+ eclipse libraries for Lombok, just for byte-buddy-dep, needed by Netbeans spi-java-hints.

This is crazy... I would never use lombok due to the following ridiculous amount of dependencies.

wlt@wlt ~
$ emerge -pv byte-buddy-dep

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] dev-java/eclipse-core-commands-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-swt-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-core-expressions-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-core-di-annotations-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-core-filesystem-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-emf-common-2.12.0:2::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-core-variables-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-compare-core-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-core-databinding-observable-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-equinox-p2-core-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/xml-commons-external-1.4.01-r10::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-equinox-bidi-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/java2html-5.0::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/spi-0.2.4::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/lombok-patcher-0.22::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/cmdreader-1.5::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/markdownj-0.4::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/commons-collections-3.3::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-jface-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-core-resources-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-text-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-core-di-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-css-core-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-help-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-equinox-p2-metadata-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-core-databinding-property-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-workbench3-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-widgets-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/commons-beanutils-1.9.3::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-core-contexts-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-jface-text-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-emf-ecore-2.12.0:2::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-core-di-extensions-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-core-filebuffers-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-jdt-core-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-css-swt-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-debug-core-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-team-core-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-equinox-p2-repository-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/commons-jxpath-1.3-r10::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-core-databinding-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-core-services-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-ltk-core-refactoring-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-emf-ecore-xmi-2.12.0:2::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-css-swt-theme-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-jface-databinding-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-emf-xpath-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-core-di-extensions-supplier-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-equinox-p2-metadata-repository-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-jdt-debug-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-core-commands-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-di-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-model-workbench-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-jdt-launching-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-equinox-p2-engine-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-services-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-bindings-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-jdt-core-manipulation-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-workbench-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-workbench-swt-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-workbench-renderers-swt-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-e4-ui-workbench-addons-swt-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-ui-workbench-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-ui-workbench-texteditor-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-ui-forms-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-ui-navigator-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-ui-views-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-ui-ide-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-ui-console-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-ui-editors-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-compare-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-debug-ui-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-team-ui-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-ltk-ui-refactoring-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-search-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/eclipse-jdt-ui-4.7:4.7::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/lombok-1.16.20::os-xtoo  USE="-doc -source" 0 KiB
[ebuild  N     ] dev-java/byte-buddy-dep-1.7.9::os-xtoo  USE="-doc -source" 0 KiB

Total: 78 packages (78 new), Size of downloads: 0 KiB

[raphw]

As a matter of fact, I have been looking into removing hashCode/equals methods from most classes as this support is not really an essential issue for Byte Buddy and since it does increase the class file size quite a bit. That it complicates the build chain is another issue that would be resolved by this, the Java 9 incomaptibility is just one issue I have faced. Things are getting worse with Java 10 and I want to keep my build free from most dependencies in the future to being able to update quicker in the future.

That said, this is quite an intensive change requiring a major release (1.8) to avoid blowing off users too much. The class file reduction would however make Byte Buddy more attractive to containers and mobile devices so it is on the list.

[wltjr]

Sweet glad it is a possibility at least and you are receptive to such someday. I would like to see if Lombok could reduce its deps in pieces. Though they haven't been to receptive to some feedback. I believe it needs some eclipse stuff for like UI integration. Not sure what all eclipse libraries it needs for actual runtime usage. Like if you develop server side app using Lombok, do you need all 70+ eclipse deps.

I haven't got a chance to mess with byte-buddy under Java 9 yet due to the lombok's own issue with Java 9. Which was not an issue at first. I have some 900+ packages building fine from source. I did have some issues with Netbeans but newer release addressed those. Now Lombok is blocking my progress on Netbeans as I need it for byte-buddy. Netbeans needs byte-buddy for Java editors deps etc. Originally I had lombok and byte-buddy for Spring 4.x. Though never finished packaging all of that, and need to move onto Spring 5. The new Kotlin deps, and Kotlin requiring bootstrap. Has me stalled on Spring 5. I cannot stand Java projects that bootstrap, and that Kotlin is new, is just bad.

I haven't got a chance to play with 10 much but I have it. I built a few things with it, and did not see any issues. Just reverted back as I am not done with 9. Not sure what issues you have seen with 10. The biggest issue I see is removal of javah. Native classes now requiring annotations if not using native classes. I need to see about some stuff for jna there. Short of class removal or other changes. Not sure how many issues I will run into with 10. Once I get past the last remaining 9 issues I will be onto 10. I am eager to checkout 10, so I am not behind as I was on Java 9. Though seems most the Java world was behind for 9. Seems like 1.5 times again.

I understand the legacy compliance. That is also an issue for Lombok and other stuff. I have been removing most all < Java 9 support from Lombok. I am not sure how things will work out going forward if there are such changes. I am essentially building and focused on a forward looking environment, presently 9+. The legacy java stuff kills me. While I have my own clients still using older code I cannot seem to motivate them to update. If it isn't broke... It costs money to update, and its hard to justify that on internal java changes vs application. Still in FOSS I rather see legacy stuff shed sooner than later.

I am not sure how things like Lombok and others will be able to support older, current, and newer JDK versions. Seems to have worked out in the past, but not sure about going forward. Seems like will have to have different code bases and build based on that, like in this example Rather than runtime detection and switching there, like Lombok does. I guess I may have some of those same issues with byte-buddy. Hard to say, need to get Lombok out of the way so I can see what issues byte-buddy may have under 9 and 10.

The lombok Java 9 blocker is rather odd. A single method I cannot for the life of me override or add. Not sure why. I believe that is the last error to getting it to build... I spent a couple hours on it and got no where thus opened issue, and also this one.

[charlesritchea]

Just wanted to note that lombok is supposed to be a a compilerOnly dependency, so those other dependencies don't need to be part of your runtime package

[wltjr]

@novaterata interesting, so your saying in deployment one does not need lombok.jar? My main concern is build time, as its build time dependencies for other stuff. Though if runtime dependencies are reduced, that does negate the admin headache of all the eclipse dependencies for lombok.

[charlesritchea]

Yes, lombok is an annotation processor, it makes Java code considerably less verbose and boiler plate by generating the verbose code at compile time. An alternative would be to introduce kotlin or similar jvm language.

…

On Fri, Jan 19, 2018, 11:18 AM William L Thomson Jr < ***@***.***> wrote: @novaterata <https://github.com/novaterata> interesting, so your saying in deployment one does not need lombok.jar? My main concern is build time, as its build time dependencies for other stuff. Though if runtime dependencies are reduced, that does negate the admin headache of all the eclipse dependencies for lombok. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#397 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABlGHdfbnSqd7UXDd3nvcnWQibdas-poks5tMMBKgaJpZM4Re0qM> .

[wltjr]

@novaterata I work with many annotation processors in Netbeans it relies on such heavily. But I do not have problems building most anything else. I am aware lombok benefits in code, seems kinda nifty. It is the packaging and building perspective I do not like. Its become a blocker to packaging other stuff. It does not seem like something i would use. Its literally blocked my progress on Java editor for Netbeans. Really just need byte-buddy, but I had to package lombok for byte-buddy for spring and now needed by Netbeans.

I am not a fan of reducing programmers effort and time just to increase systems admin and others. I am not as annoyed by boilerplate code. I code in C and routine have such. Its life in coding. I do not see how Lombok benefits runtime really. It seems more like a RAD only tool.

[wltjr]

If there is anything I can do to assist with this I am more than willing. I do not need lombok but I do need byte-buddy, its presently blocking the core Java stuff for my Netbeans 9 build from source under JDK9. Not sure Lombok will be fixed for Java 9 anytime soon. Thus since I am stalled there, I have time to help.

[charlesritchea]

The lombok plugin for Intellij and maybe eclipse has a great delombok feature that should make this easy

…

On Sat, Jan 20, 2018, 1:11 PM William L Thomson Jr ***@***.***> wrote: If there is anything I can do to assist with this I am more than willing. I do not need lombok but I do need byte-buddy, its presently blocking the core Java stuff for my Netbeans 9 build from source under JDK9. Not sure Lombok will be fixed for Java 9 anytime soon. Thus since I am stalled there, I have time to help. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#397 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABlGHdyWO01kI3uIXGR59mUmfL5fjZeTks5tMixJgaJpZM4Re0qM> .

[wltjr]

That is good to know, but dont use either, always been a Netbeaner. Likely could grab a Intellij binary or something. Maybe I can invoke via cli outside of IDE for same purposes. Though think I need a built and running lombok. I had a binary of that and byte-buddy, but all there deps were updated to 9. Not sure I can run or build those. I likely would have to under 1.8, and thus recompile any deps for lombok/byte-buddy. Not really an option long past that point. Seems lombok has run issues under 9 beyond build. Not sure about prebuilt older versions.

Thanks for the suggestion. I may look into that. Anxious to get around the blocker so I can complete my NB efforts. Netbeans already addressed their Java 9 issues, down to just dependencies. Curious if byte-buddy will have build and other issues. Won't know till I get past lombok...

[wltjr]

It looks like the only use is of lombok.EqualsAndHashCode. I think just need to find a replacement for that annotation, alternative library, custom annotation processor for such or something. Though looking at tests, before and after, may not be so simple. But at least does show the difference of delombok.

[wltjr]

Seems Google Auto-Value provides the same function. I will experiment with replacement.

[wltjr]

Retracted for now, jar was empty... need to look further into what happened.

[wltjr]

Ok I am not crazy and looking to confirm again. I need to verify more via runtime and usage. I can submit PR if you like. Presently using the following sed. I had posted before and removed.

To make the change from lombok to 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}" || die "Failed to swap lombok for autovalve"
done

Not sure what went wrong before, passed compile, but no jar thus remove comment. I think I did not specify processor. Java 9 seems odd with processors, not picking it up from processor or source paths. Just classpath when using -processor argument. Passing those for netbeans as well. Seems they should be picked up via a path, processor or source.

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

But it builds fine with switch from Lombok to Auto-Value. Now to see if other stuff builds against it and runs etc. Hopefully I can proceed with the blocked needed bits of Netbeans now.

dev ~
unzip -l /usr/share/byte-buddy-dep/lib/byte-buddy-dep.jar
....
  5442958                     1928 files

dev ~
# cat /usr/share/byte-buddy-dep/package.env
DESCRIPTION="Runtime code generation for the Java virtual machine."
SLOT="0"
CATEGORY="dev-java"
PVR="1.7.9"
CLASSPATH="/usr/share/byte-buddy-dep/lib/byte-buddy-dep.jar"
DEPEND="asm-6:auto-common:auto-value:guava-23:spotbugs-annotations"
VM=">=virtual/jre-9"
RELEASE="9"
MERGE_VM="oracle-jdk-bin-9"

[wltjr]

Not sure how to confirm runtime usage. But I am not getting any errors in Netbeans for byte-buddy-dep built with AutoValue vs Lombok. I will comment if I run into any. Aside from build issues in the PR. Seems the change is safe. Just one auto code generator for another. Seems AutoValue is a drop in replacement for the most part, less some configuration/customization.

[vlsi]

@wltjr, ByteBuddy uses at least the following patterns
@EqualsAndHashCode(callSuper = false)
@EqualsAndHashCode(exclude = "name")
@EqualsAndHashCode(callSuper = false, of = "prefix")
Are you sure AutoValue provides exact match for that annotations?

[wltjr]

@vlsi I am not sure on that stuff. I looked at AutoValue docs online and did not see equivalents, though I could be wrong. It may require some other changes to code to replicate such if AutoValue does not. Or have such added to newer version of AutoValue.

I have to check on what Lombok does with each, but this maybe a replacement for @EqualsAndHashCode(exclude = "name") but requires changes to code. It cannot be done via annotations like Lombok.

The other question to ask is if AutoValue needs those things that Lombok did. It may work differently and not require such. I am not very familiar with code generators like Lombok and AutoValue. I just know Lombok is a pita to build from source for my needs and in my build env not using ant, etc.

[raphw]

Lombok is no longer used as of Byte Buddy 1.8.3 which now builds based on its own, previous version.

[wltjr]

@raphw thanks a lot!!! Your the man! Or one of them!