Hi Daniel, can you explain what the advantages and disadvantages are?
Is it worth the introduction of an additional framework, more complex IDE configuration, an additional Gradle plugin and more memory consumption and why?
Thanks for clarification, Michael Brohl ecomify GmbH - www.ecomify.de Am 28.07.20 um 14:44 schrieb Daniel Watford:
Hello, Back in April the possibility of using Lombok for the generation of some boilerplate code was mentioned on the mailing list [1]. As part of work-in-progress on OFBIZ-11900 (refactoring MacroFormRenderer) I have used Lombok on a few small classes. The work-in-progress branch can be found at [2]. Only a small amount of Lombok has been used so far, meaning it shouldn't be too difficult to remove it if needed. In build.gradle I have used the FreeFair Gradle Lombok plugin [3] referenced by the Lombok Project [4]. Building with the lombok plugin seemed to use a lot of memory and caused gradle to garbage collect and run out of heap regularly. To resolve this I increased the about of memory available to gradle in gradle.properties using: org.gradle.jvmargs=-Xmx2g -XX\:MaxHeapSize\=4g Tuning this might be important depending on the CI infrastructure used by the Ofbiz project. You will likely need your IDE to apply annotation processing otherwise you might see warning of missing methods. In IntelliJ I use what appears to be the de facto Lombok plugin [5]. Guidance is available from the Lombok project for other IDEs [6]. Lombok @ToString annotations have been applied to RenderableFtlString and RenderableFtlNoop. This causes Lombok to insert toString() methods into the classes based on the class names and field values. The @Value annotation has been applied to MacroCallParameterStringValue, MacroCallParameterBooleanValue and MacroCallParameterMapValue. This annotation turns those classes into immutable-like entities, where all fields must be set in the inserted constructor and are available from automatically inserted getters. ToString(), equals and hashCode() methods are also created meaning these classes can be relied upon as map keys if needed. The @Builder annotation has been applied to RenderableFtlMacroCall and RenderableFtlSequence. This annotation does quite a lot so I'd recommend you run delombok (instructions below) to see the code that Lombok inserts for us. To see the sources generated by Lombok we can run DeLombok. At the command line execute: ./gradlew delombok A copy of all sources (not just those with lombok annotations) will be placed under build/delombok. Please take a look at the delomboked sources for the above classes under build/delombok/main/org/apache/ofbiz/widget/renderer/macro/parameter and build/delombok/main/org/apache/ofbiz/widget/renderer/macro/renderable. Please let me know what you think about this usage of Lombok. Thanks, Dan. [1] - http://ofbiz.135035.n4.nabble.com/Default-constructors-in-JAVA-classes-tp4749257p4749258.html [2] - https://github.com/danwatford/ofbiz-framework/tree/OFBIZ-11900-WIP [3] - https://plugins.gradle.org/plugin/io.freefair.lombok [4] - https://projectlombok.org/setup/gradle [5] - https://plugins.jetbrains.com/plugin/6317-lombok/ [6] - https://projectlombok.org/setup/overview
smime.p7s
Description: S/MIME Cryptographic Signature