Expand my Community achievements bar.

Join expert-led, customer-led sessions on Adobe Experience Manager Assets on August 20th at our Skill Exchange.
SOLVED

Lombok library embedding in Maven

Avatar

Level 2

Our team wants to explore using Lombok annotations (like @getter, @Setter, @Builder) in Sling Models that we export via Sling Model Exporter in AEM. What are the consequences, best practices, and advantages of using Lombok in this context?

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @PriyankaKh4,

Using Lombok in Sling Models exported through Sling Model Exporter can bring benefits but also has considerations. Here’s a breakdown:

Advantages:
  • Less Boilerplate: Lombok drastically reduces boilerplate code by auto-generating getters, setters, constructors, builders, and more, making your Sling Models cleaner and easier to maintain.

  • Consistency: Generates consistent, standard Java bean getters and setters that Sling Model Exporter relies on for JSON serialization.

  • Improved Readability: Cleaner code helps teams focus on business logic rather than repetitive method definitions.

  • Supports Jackson Annotations: Lombok works well with Jackson annotations (e.g., @JsonIgnore, @JsonProperty), so you can customize JSON output easily.

Consequences & Considerations:
  • Compile-Time Dependency: Lombok generates code only at compile time, so your build process must include Lombok. IDEs need Lombok plugins to avoid showing errors.

  • Injection Annotations Still Needed: You still need Sling’s @Inject annotations for dependency injection; Lombok doesn’t replace AEM injection.

  • No-Arg Constructor Requirement: Sling Models require a no-argument constructor. Using Lombok’s @Builder or other constructors must not break this requirement.

  • Debugging Complexity: Debugging issues can be slightly harder since Lombok-generated code isn’t visible in source, though IDEs typically handle this well.

  • Team Familiarity: Teams unfamiliar with Lombok may face a learning curve.

Best Practices:
  • Continue using Sling’s injection annotations (@Inject) on fields or constructors.

  • Avoid removing no-arg constructors if using Lombok builders or all-args constructors.

  • Annotate either fields or generated getters with Jackson annotations for JSON customization.

  • Ensure your build system and IDE are configured for Lombok support.

  • Use Lombok to reduce boilerplate but avoid overusing advanced features that might conflict with Sling’s model adaptation.

Official Reference for context:

 https://projectlombok.org/

Similar Discussions:


Santosh Sai

AEM BlogsLinkedIn


View solution in original post

1 Reply

Avatar

Correct answer by
Community Advisor

Hi @PriyankaKh4,

Using Lombok in Sling Models exported through Sling Model Exporter can bring benefits but also has considerations. Here’s a breakdown:

Advantages:
  • Less Boilerplate: Lombok drastically reduces boilerplate code by auto-generating getters, setters, constructors, builders, and more, making your Sling Models cleaner and easier to maintain.

  • Consistency: Generates consistent, standard Java bean getters and setters that Sling Model Exporter relies on for JSON serialization.

  • Improved Readability: Cleaner code helps teams focus on business logic rather than repetitive method definitions.

  • Supports Jackson Annotations: Lombok works well with Jackson annotations (e.g., @JsonIgnore, @JsonProperty), so you can customize JSON output easily.

Consequences & Considerations:
  • Compile-Time Dependency: Lombok generates code only at compile time, so your build process must include Lombok. IDEs need Lombok plugins to avoid showing errors.

  • Injection Annotations Still Needed: You still need Sling’s @Inject annotations for dependency injection; Lombok doesn’t replace AEM injection.

  • No-Arg Constructor Requirement: Sling Models require a no-argument constructor. Using Lombok’s @Builder or other constructors must not break this requirement.

  • Debugging Complexity: Debugging issues can be slightly harder since Lombok-generated code isn’t visible in source, though IDEs typically handle this well.

  • Team Familiarity: Teams unfamiliar with Lombok may face a learning curve.

Best Practices:
  • Continue using Sling’s injection annotations (@Inject) on fields or constructors.

  • Avoid removing no-arg constructors if using Lombok builders or all-args constructors.

  • Annotate either fields or generated getters with Jackson annotations for JSON customization.

  • Ensure your build system and IDE are configured for Lombok support.

  • Use Lombok to reduce boilerplate but avoid overusing advanced features that might conflict with Sling’s model adaptation.

Official Reference for context:

 https://projectlombok.org/

Similar Discussions:


Santosh Sai

AEM BlogsLinkedIn