Fluent Setters Not working with EnhancedClient

[patrickjamesbarry]

Describe the bug

Our pojos/beans used with DynamoDbMapper (v1) used to work with fluent setters. This seems to be broken when using the EnhancedClient with v2.

Expected Behavior

expectation is that this bean would work (the name attribute would be set

@DynamodbBean
public MyClass{
 private String name;
  public MyClass setName(String name){
     this.name = name;
     return this;
  }
}

Current Behavior

The attribute using a fluent setter does not work and the attribute will always be null

Reproduction Steps

1. Create instance of EnhancedClient
2. Create DynamodbBean like above to represent an item in the table
3. Create table schema using DynamodbBean
4. Save item to table and observe null for 'name'

Possible Solution

No response

Additional Information/Context

This has been reported in other tickets, but there has been no ticket created to fix or add this support. example: https://github.com/aws/aws-sdk-java-v2/issues/2213

AWS Java SDK version used

2.25.2

JDK version used

openjdk version "17.0.7" 2023-04-18

Operating System and version

mac 13.6.4

[debora-ito]

@patrickjamesbarry as I mentioned in the documentation issue, I don't think fluent setters were in scope in the design. I'm changing this to a feature request to add support to fluent setters.

[debora-ito]

@patrickjamesbarry discussed this with the rest of the team, and even though the v2 Enhanced Client bean doesn't support fluent setters like v1 Mapper, we'd like to keep to the standard bean concept.

We'd like to know more about the impact of the lack of fluent setters in your use case. Is it for the coding experience? Or maybe you/your team don't have control over how the bean classes are created?

Have you considered using Immutable classes?

[patrickjamesbarry]

Looking through stackoverflow and github issues, you can see the oversight of this feature has burned many. So the initial submittal of this ticket was simply to formalize the request to patch this change.

Why does the community want fluent setters? A quick google says it best: "By implementing a fluent setters, we use less code, we don't declare or refer to local variables, we require lower cognitive load, and we don't change the meaning. The hierarchy in the code reflects the nesting of the objects, of the fields to fill out. You can also notice the nesting visually"

Jumping into your suggestion: We looked at the Immutable class which requires you to embed yet another Builder class inside of it. There is alot of boiler plate code in java that makes it very verbose to write and this is another example of added cruft to write.

A better alternative would be to support java record classes. https://www.baeldung.com/java-record-keyword Is this supported?