Lombok: Question: Is there a way to make collections unmodifiable on getter to improve encapsulation ?

[ignaciolarranaga]

Let me show the question with a sample code, let suppose this:

public Set<String> getAccountNumbers() {
    return accountNumbers == null ? null : Collections.unmodifiableSet(accountNumbers);
}

Instead of returning the original collection we return an unmodifiable copy in order to avoid undesired modifications of the object's collection.
I found references on the web (like this one: https://stackoverflow.com/questions/34589949/lombok-getter-and-copies-of-collections) but not answers.

The same problem might be pointed out on the setters/constructors like receiving a collection that can be mutated after set/used. Let say:

List<String> creditCards = Arrays.asList("1231321", "1231312322");
Person p = new Person(creditCards);
...
creditCards.clear();
...

If you can also grab me some feedback about this I'll appreciate.

Thanks in advance for the response.

[rspilker]

No

[ignaciolarranaga]

@rspilker Do you think a PR to add something like this will be useful ?

[dylan-chong]

@ignaciolarranaga Hell yes! Collections.unmodifiableX is just another boilerplate that we shouldn't have to write ourselves

[dylan-chong]

Copying collections passed into the constructor is another thing to consider as well, but that might be best in a separate issue...

[rspilker]

I wouldn't start working on a pull request.

If we're going to add something, it will be in a way that allows getters to make a safecopy of the field or wrap it in something unmodifiable. This is not a collections-only concern.

The same might go for setters: you might need to make a safecopy for internal storage, because if you store a reference, the caller might modify the original object.

In this case, constructors and setters are the same.

Potential candidates for copying/wrapping in occurring order:

• Collections
• Arrays
• Date/Calendar
• Other mutable objects

[juanmbellini]

Will this issue be solved?

[Maaartinus]

@juanmbellini I'm afraid, no. It's closed and there are tons of other feature requests. Adding anything to Lombok is way more complicated that adding a method to a library.

This feature has quite a few problems:

• too many cases to handle
• too many options
  
  
  
  • wrapping or cloning?
  
  
  • unmodifiable wrapper or Guava's immutable collection or what?
  
  
  • dependent on declared type or runtime type?
  
  
  • what about arrays? they have no unmodifiable wrapper
  
  

[GF4711]

Why not just create it for the types "Set", "List", "Map" and only on Getters before moving this to the trash can because you have to change to much? Step by Step! You don't have to integrate it everywhere you can. Just start out with a small change and what is requested.

Collections.unmodifiable... should be enough.

[raman-nbg]

Its the year 2021 and we still can't create an unmodifiable collection with lombok :(

[sergeykad]

The documentation states that "@Value is the immutable variant of @Data", however, due to this bug it is not the case. I understand that fully fixing it can be impractical, but wrapping returned collections with Collections.unmodifiableX will at least fix some of the cases.
It should not be all or nothing. Partially fixing this bug should be enough for most purposes.