Immutable DynamoDb Value.Style Suggestions + Documentation Update about immutables HOT 7 OPEN

Do you remember the limitation that led to the documentation "Nullable collections and other special types are not supported"?

May implementations of immutable collections, including Guava's and JDK 9 immutable collections do not support nulls as elements. Even with jdkOnly=true we ban nulls (unless @AllowNulls or @SkipNulls). Overall, the problem with null is that it is not typed (@Nullable annotations and Optional can be used as an improvement, but still) and that developers, as result, overuse null in the wrong contexts, most of the time where it's not intended. I don't think that the fact that some concurrent data-structures use null for special things (and therefore do not allow null as values) is something which should be overly important, I think it's just something implementation specific and not hugely relevant in the art of avoiding nulls. The software quality improves significantly when majority/all of developers no longer use null for arbitrary purposes (but don't ask me to provide research paper or a prove this is as a theorem, for me this is just certain observation).
I even think that it's not an overkill to use smth like List<Optional<T>> where this is what actually was meant - a list of elements where specific positions are absent. For the Map and Set even that is barely makes sense, there is no "positions", so something is more naturally is either included in set or not, either have value (for a key) or not, the need for null(or Optional.empty()) as a set element or as a value of a key is very rarely justifiable. So when I see in data/JSON something like this [null, "a", null, null, "bc"] in 99% of cases this is bad data design or just programming error (silent errors resulting in undefined result which somehow turns into null), I do understand that sometimes this is necessary, that's why we can use List<Optional<T>> or List<@AllowNulls T> and hopefully it will be documented why it's necessary

from immutables.

// this works when jdkOnly = true or when no guava found on classpath
// @AllowNulls - your own annotations with same simple name
@Nullable List<@AllowNulls String> attr();
// can be type_use or a method level annotation

will see if it's easy to suppress from method (I've though it was)

Updating the documentation would be very welcome (src branch in immutables.github.io repo)

Guess we need to find / fix some more workarounds. What's left except that from method? Handling partials (partially initialized) is hard in any setup. Have you tried to messing around with Modifiable (builder-in-disguise, search issues for more info) ?

from immutables.

will see if it's easy to suppress from method (I've though it was)

That'd be great, I didn't see anything when reading through the @Value javadoc. If strict builders are the only approach then i'd be interested in implementing an option to suppress from?

// this works when jdkOnly = true or when no guava found on classpath
// @AllowNulls - your own annotations with same simple name
@nullable List<@AllowNulls String> attr();

@Nullable collection attributes are actually working perfectly when testing, even with guava collections. I vaguely remember it causing problems a few weeks ago, but maybe that was with a different @Value.Style I was experimenting with. Do you remember the limitation that led to the documentation "Nullable collections and other special types are not supported"?

Although maybe jdkOnly = true makes sense either way for this style since dynamo supports null collection elements?

Handling partials (partially initialized) is hard in any setup. Have you tried to messing around with Modifiable (builder-in-disguise, search issues for more info) ?

I got partials working by extending the non-partial interface and using the style option of validationMethod = ValidationMethod.NONE.
Note that this generate a warning but it hasn't caused any issues:

[WARNING] /Users/sswartz/workspace/dynamodb-enhance-client-scratch/src/main/java/org/swar8080/dynamodbenhancedscratch/immutables/CustomerUpdate.java:[9,8] 

(immutables:subtype) Should not inherit org.swar8080.dynamodbenhancedscratch.immutables.Customer which is a value type itself. Avoid extending from another abstract value type. 

Better to share common abstract class or interface which are not carrying @Immutable annotation. If still extending from immutable abstract type be ready to face some incoherences in generated types.

In the new documentation we could do what's recommended by that warning, but it'd be more convenient having 2 classes instead of 3

from immutables.

Let me know if it's worth adding the documentation with the current approach and strict builders limitation. I can update it if/when I add an option to skip generating the from method.

from immutables.

Yes, documentation about styles and usage are very welcome, definitely it needs an update. Feel free to PR src branch in immutables.github.io repo

I'm looking into from method. If this will work, in 2.10.0 we will be able to use Style(from="", to disable from method, by using empty string as a naming pattern.

BTW @SuppressWarnings("immutables:subtype") can be put on a class or package to silence "Should not inherit.."

from immutables.

I'm looking into from method. If this will work, in 2.10.0 we will be able to use Style(from="", to disable from method, by using empty string as a naming pattern.

Alright, i'll open a MR for the updated dynamodb documentation that assumes Style(from="" will work once 2.10 is released

For the Nullable collection documentation, I was interpreting it as saying the collection itself can't be nullable, like @Nullable List<String> foo, but so far that hasn't caused me any problems. In the dynamo documentation I won't mention that as a limitation then

And also it sounds like the dynamodb documentation shouldn't mention jdkOnly=true, and instead leave it up to people to add if they want. I also think null collection elements are a code smell

from immutables.

yes, these are separate concerns, whether collection itself can be absent @Nullable, or what's happening with its elements (@AllowNulls/@SkipNulls). Yep, the said element annotations and jdkOnly can be irrelevant.
Having collection itself as a @Nullable will prevent defaulting it to an empty collection, which is sometimes is ok and sometimes is not, so having collection nullable is a useful tool.

from immutables.