1. Overview

It’s pretty typical to have get and set methods in our domain objects, but there are other ways that we may find more expressive.

In this tutorial, we’ll learn about Project Lombok‘s @Accessors annotation and its support for fluent, chained, and custom accessors.

Before continuing, though, our IDE will need Lombok installed.

2. Standard Accessors

Before we look at the @Accessors annotation, let’s review how Lombok treats the @Getter and @Setter annotations by default.

First, let’s create our class:

@Getter
@Setter
public class StandardAccount {
    private String name;
    private BigDecimal balance;
}

And now let’s create a test case. We can see in our test that Lombok has added typical getter and setter methods:

@Test
public void whenStandardAccount_thenHaveStandardAccessors() {
    StandardAccount account = new StandardAccount();
    account.setName("Standard Accessors");
    account.setBalance(BigDecimal.TEN);

    assertEquals("Standard Accessors", account.getName());
    assertEquals(BigDecimal.TEN, account.getBalance()); 
}

*We’ll see how this test case changes as we look at @Accessor‘s options.*

3. Fluent Accessors

Let’s begin with the fluent option:

@Accessors(fluent = true)

The fluent option gives us accessors that don’t have a get or set prefix.

We’ll take a look at the chain option in a moment, but since it’s enabled by default, let’s disable it explicitly for now:

@Accessors(fluent = true, chain = false)
@Getter
@Setter
public class FluentAccount {
    private String name;
    private BigDecimal balance;
}

Now, our test still behaves the same, but we’ve changed the way we access and mutate state:

@Test
public void whenFluentAccount_thenHaveFluentAccessors() {
    FluentAccount account = new FluentAccount();
    account.name("Fluent Account");
    account.balance(BigDecimal.TEN);

    assertEquals("Fluent Account", account.name()); 
    assertEquals(BigDecimal.TEN, account.balance());
}

Notice how the get and set prefixes have disappeared.

4. Chained Accessors

Now let’s take a look at the chain option:

@Accessors(chain = true)

The chain option gives us setters that return this. Again note that it defaults to true, but we’ll set it explicitly for clarity.

This means we can chain multiple set operations together in one statement.

Let’s build on our fluent accessors and change the chain option to true:

@Accessors(fluent = true, chain = true)
@Getter 
@Setter 
public class ChainedFluentAccount { 
    private String name; 
    private BigDecimal balance;
}

We get the same effect if we leave out chain and just specify:

@Accessors(fluent = true)

And now let’s see how this affects our test case:

@Test
public void whenChainedFluentAccount_thenHaveChainedFluentAccessors() {
    ChainedFluentAccount account = new ChainedFluentAccount()
      .name("Fluent Account")
      .balance(BigDecimal.TEN);

    assertEquals("Fluent Account", account.name()); 
    assertEquals(BigDecimal.TEN, account.balance());
}

Notice how the new statement becomes longer with the setters chained together, removing some boilerplate.

This, of course, is how Lombok’s @Builder makes use of chained fluent accessors.

5. Prefix Accessors

At times our fields may have a different naming convention than we’d like to expose via getters and setters.

Let’s consider the following class that uses Hungarian Notation for its fields:

public class PrefixedAccount { 
    private String sName; 
    private BigDecimal bdBalance; 
}

If we were to expose this with @Getter and @Setter, we’d get methods like getSName, which isn’t quite as readable.

The prefix option allows us to tell Lombok which prefixes to ignore:

@Accessors(prefix = {"s", "bd"})
@Getter
@Setter
public class PrefixedAccount {
    private String sName;
    private BigDecimal bdBalance;
}

So, let’s see how that affects our test case:

@Test
public void whenPrefixedAccount_thenRemovePrefixFromAccessors() {
    PrefixedAccount account = new PrefixedAccount();
    account.setName("Prefixed Fields");
    account.setBalance(BigDecimal.TEN);

    assertEquals("Prefixed Fields", account.getName()); 
    assertEquals(BigDecimal.TEN, account.getBalance());
}

Notice how the accessors for our sName field (setName, getName) omit the leading s and the accessors for bdBalance omit the leading bd.

However, Lombok only applies prefixes when a prefix is followed by something other than a lowercase letter.

This makes sure that if we have a field that isn’t using Hungarian Notation, such as state, but starts with one of our prefixes, s, we don’t end up with getTate()!

Lastly, let’s say we want to use underscores in our notation but also want to follow it with a lowercase letter.

Let’s add a field s_notes with prefix s_:

@Accessors(prefix = "s_")
private String s_notes;

Following the lowercase letter rule we’d get methods like getS_Notes(), so Lombok also applies prefixes when a prefix itself ends in something that isn’t a letter.

6. Final Accessors

Finally, since version v1.18.24, Lombok supports the makeFinal option to make the generated getters and setters final:

@Accessors(makeFinal = true)

This is pretty helpful when our class has subclasses, but they aren’t allowed to override our getters and setters.

So next, let’s create a FinalAccount class with this option:

@Accessors(makeFinal = true)
@Getter
@Setter
public class FinalAccount {
    private String name;
    private BigDecimal balance;
}

Now let’s write a test to verify if the getters and setters work as usual and whether they are final methods:

@Test
public void whenFinalAccount_thenHaveFinalAccessors() {
    FinalAccount account = new FinalAccount();
    account.setName("Final Account");
    account.setBalance(BigDecimal.TEN);

    assertEquals("Final Account", account.getName());
    assertEquals(BigDecimal.TEN, account.getBalance());

    //verify if all getters and setters are final methods
    boolean getterSettersAreFinal = Arrays.stream(FinalAccount.class.getMethods())
      .filter(method -> method.getName().matches("^(get|set)(Name|Balance)$"))
      .allMatch(method -> Modifier.isFinal(method.getModifiers()));
    assertTrue(getterSettersAreFinal);

}

In the test above, we first proved whether the getters and setters work as expected. Then, we used the Java Reflection API to verify if the getters and setters are final methods.

Of course, the makeFinal option can work together with other @Accessors options. Let’s see another example:

@Accessors(makeFinal = true, fluent = true, chain = true)
@Getter
@Setter
public class FinalChainedFluentAccount {
    private String name;
    private BigDecimal balance;
}

As the FinalChainedFluentAccount class shows, this time, we combine the makeFinal option together with fluent and chain. And let’s see how this affects our test case:

@Test
public void whenFinalChainedFluentAccount_thenHaveFinalAccessors() {
    FinalChainedFluentAccount account = new FinalChainedFluentAccount();
    account
      .name("Final Chained Fluent Account")
      .balance(BigDecimal.TEN);

    assertEquals("Final Chained Fluent Account", account.name());
    assertEquals(BigDecimal.TEN, account.balance());

    //verify if all getters and setters are final methods
    boolean getterSettersAreFinal = Arrays.stream(FinalAccount.class.getMethods())
      .filter(method -> method.getName().matches("^(name|balance)$"))
      .allMatch(method -> Modifier.isFinal(method.getModifiers()));
    assertTrue(getterSettersAreFinal);
}

As we can see in the test, the fluent methods name() and balance() are final.

7. Configuration Properties

We can set a project- or directory-wide default for our favorite combination of settings by adding configuration properties to a lombok.config file:

lombok.accessors.chain=true
lombok.accessors.fluent=true

See the Lombok Feature Configuration Guide for further details.

8. Conclusion

In this article, we used the fluent, chain, and prefix options of Lombok’s @Accessors annotation in various combinations to see how it affected the generated code.

To learn more, be sure to take a look at the Lombok Accessors JavaDoc and Experimental Feature Guide.

As usual, the source for this article is available over on GitHub.