@Nullable List and Set initialized as empty become null after Java serialization/deserialization

[RJoker0]

Good day,
We are using immutables 2.8.2 and realized that if we have a @Nullable Set or List fields which are initialized with an empty collection then after Java serialization/deserialization they become nulls.
At the same time, @Nullable Collection fields remain empty collections what I consider expected behavior.

This happens because the generated code is different by some reason between List/Set and Collection fields in the generated SerialForm nested class:

if (instance.collection() != null) {
    names.add("collection");
    values.add(instance.collection());
  }

  if (instance.set() == null) {
    names.add("set");
    values.add(null);
  } else if (!instance.set().isEmpty()) {
    names.add("set");
    values.add(instance.set().toArray());
  }

  if (instance.list() == null) {
    names.add("list");
    values.add(null);
  } else if (!instance.list().isEmpty()) {
    names.add("list");
    values.add(instance.list().toArray());
  }

Would it be possible to change Set and List behavior to the same as for Collections.

Thanks in advance!
immutables-sample.zip

[elucash]

will look into that, thank you. I think that code is not completely wrong for being not the same for regular collections (Collection attributes are not recognized as "collections" at all for being too abstract, there's an obscure note about that in collection section in the user guide), but it's definitely not right either, as nullable collection should support null. It could be there are hard to "fix" or intentional limitations for nullable collections in general, will see.

[RJoker0]

Thank you, Eugene. 

Maybe just a few words about our use-case: we use generated "request objects" to search for some domain entities (ex. devices). "Request objects" contain all the possible criteria, ex. names, types, locations, etc., which are collections.

We need to distinguish two cases:

• no criterion provided at all (ex. no types) - this means that we should ignore this criterion completely while searching (we use null Set to represent this)
• empty criterion provided (ex. empty collection of types) - this means that by some reason a client has given to us no acceptable values (we use empty Set to represent this). Yes, in this case nothing will be found and returned to the client - client side could programmatically compose those criteria and not even realize that some criteria are empty.

Cheers
Roman

[RJoker0]

Dear Eugene,
is there any news regarding this problem?
Thanks!
Roman

[elucash]

Thanks for reminding, seems like I found the solution, yet was a bit puzzling to figure out where the logical mistake was. I'm merging to master, will release in beta3 in 1-2 days

[RJoker0]

Thank you very much, Eugene! Roman

…

On Sat, May 29, 2021 at 4:38 AM Eugene Lukash ***@***.***> wrote: Thanks for reminding, seems to found the solution, yet was a bit puzzling to figure out where the logical mistake was. I'm merging to master, will release in beta3 in 1-2 days — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1295 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AT4MQEN6MDTKRXP6H4B5CADTQBHT5ANCNFSM432B2UOQ> .

[RJoker0]

Dear Eugene,
when do you plan to release the fix?
Thanks!
Roman

[elucash]

Hi Roman, only now I've managed to return to this, released in 2.9.0-beta3

[RJoker0]

Thank you very much, Eugene!
2.9.0-beta3 works for me.
When do you plan to make it proper 2.9.0 release?
Cheers
Roman

[asereda-gs]

We're planning to release 2.9.0 within couple of weeks

[RJoker0]

Dear @elucash and @asereda-gs ,
2.9.0 is not yet released, right?
When do you plan to release it?
Thanks!
Roman

[elucash]

@RJoker0 I'm very sorry for the seemingly endless delays, we had extremely small amount of time that we could dedicate to that in the light of some hard to troubleshoot issues. I've carved some time for the last ditch effort to address known issues with the goal to release with whatever remains. Wish me good luck tonight :)

[RJoker0]

Good luck, Eugene!

…

On Fri, Jan 14, 2022 at 4:13 AM Eugene Lukash ***@***.***> wrote: @RJoker0 <https://github.com/RJoker0> I'm very sorry for the seemingly endless delays, we had extremely small amount of time that we could dedicate to that in the light of some hard to troubleshoot issues. I've carved some time for the last ditch effort to address known issues with the goal to release with whatever remains. Wish me good luck tonight :) — Reply to this email directly, view it on GitHub <#1295 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AT4MQEJ3GEYK6GF6TGGQLEDUV6IF3ANCNFSM432B2UOQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[elucash]

released in 2.9.0 at last