Jackson encoding is broken about immutables-vavr HOT 12 CLOSED

I can confirm that your latest commits fix my use cases above. Nice job, especially considering that I've reported the bug just an hour ago! Thanks!

from immutables-vavr.

Seems like a low-cost change to improve serialization. I'll add it now.

from immutables-vavr.

This may be corrected in the 0.4.0-SNAPSHOT I just pushed.

from immutables-vavr.

It indeed seems to be fixed for Option! But, it is not limited to Options: List, Map, Set, and probably others, also seem to be affected.

from immutables-vavr.

Is it the same error for the List, Map, etc, types?

Error:java: Could not generate constructor. Attribute 'bar' does not have default value.

I have to admit that I don't fully understand the underlying issue. If all that's needed to fix it is adding @Encoding.Copy methods, then I can easily get that done.

from immutables-vavr.

Yes, it is the same error. With the latest version from branch develop:

@Value.Immutable
@VavrEncodingEnabled
@JsonSerialize
@JsonDeserialize
public interface Foo {
    Option<String> option();
    List<String> list();
    Set<String> set();
    Map<String, Integer> map();
}

Results in the compiler errors:

Error:java: Could not generate constructor. Attribute 'list' does not have default value.
Error:java: Could not generate constructor. Attribute 'set' does not have default value.
Error:java: Could not generate constructor. Attribute 'map' does not have default value.

Option is fixed now, and JSON encoding/decoding also works.

from immutables-vavr.

Ah, so presumably it's just a matter of providing a default value for the @Encoding.Impl field. I'll update all of the types now.

from immutables-vavr.

Have a go with the snapshot I just pushed (20170702.120216).

from immutables-vavr.

I'll likely push a release today if @emmanueltouzery confirms the snapshot as working.

from immutables-vavr.

hmm i won't manage to test it today. tomorrow best case. i'd say go for it. i think in the case of our setup, we'll probably stick with a small-scale local implementation which supports only option, which is enough for us, we probably won't migrate to using this library.

from immutables-vavr.

Got it!

from immutables-vavr.

Great! 👍

Just one thing: I've noticed that you've introduced empty HashSet and HashMap as default values for Set and Map. Usually, I prefer to use the Linked versions of these classes, as they have a useful ordering semantics: converting JSON to some object and back again leads to the same JSON. This makes it easier to write tests, and also to compare for differences in case something fails (which is difficult if the ordering of elements is arbitrary).

What do you think? Does it make sense to you to use LinkedHash[Set/Map] as defaults?

To me, it's not a serious issue what the defaults are, as I can always just directly use the type LinkedHash[Set/Map] in my immutable data types, though I'd prefer not to, as LinkedHash adds 10 more characters. :(

from immutables-vavr.