Mapping Immutable Objects?

[John Smith]

What is the approach for mapping between two Immutable objects? The examples do not address this. Thanks. J

[Jonathan Halterman]

Hi John,

I don't have any documented examples since this hasn't come up yet, but assuming your object is immutable by way of using something like private final fields, there are two approaches I can think of. I just pushed a simple test that illustrates:

https://github.com/jhalterman/modelmapper/blob/22936dd64ad99eea625df63d8ce316977b56eeb7/core/src/test/java/org/modelmapper/functional/Immutable.java

One approach is to use a Provider to construct your object by explicitly passing the values from the source object into the destination object's constructor. 

The second approach is to simply default your destination object values to something (like null) and configure ModelMapper to enable field matching and to set the field access level to private. This allows ModelMapper to map source properties to destination properties that happen to be private fields.

Hope this helps,

Jonathan

[John Smith]

Thanks for the suggestions and tests. The Provider approach is a nice solution. Thanks. J

[Adam Gent]

Jon, I just stumbled on to your library.

I too would love Immutable object support as my library depends on it: https://github.com/agentgt/jirm

Right now I have been relying on Jackson's Immutable object support which is very very good. 

For my immutable ORM (sort of a misnomer..) I map immutable objects to Map<String,Object> to and from ResultSet and JDBC Object[].

Jackson supports immutable object through constructor annotations and jOOQ (thanks to my whining and complaining to Lukas) supports @ConstructorProperties annotation.

Perhaps ModelMapper could support @ConstructorProperties (google the annotation)?

Thanks

-Adam

[Jonathan Halterman]

Hey Adam,

jirm looks interesting. As far as I know, immutable objects aren't a problem for ModelMapper since it overrides object security (see the Immutable example in that link above). But I can certainly see the value of ConstructorProperties for populating property values. 

One core aspect of ModelMapper is that it matches accessor names in some source type to mutator names in some destination type. I assume that ConstructorProperties usage means that mutators are not necessary, in which case ModelMapper could use the annotated property names to represent the "mutator" names to match accessors to. What do you think? I created an issue to track this.

- jonathan

[Adam Gent]

Jon,
Exactly what I want. I prefer the library setting the properties via
the contructor as it seems less disingenuous and more threadsafe
(given Java's memory model).
Curious: I know that Hibernate will even set `private final` variables
regardless of the `final`. Does Modelmapper do so likewise?

-Adam

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "modelmapper" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/modelmapper/F6GrvfmF814/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> modelmapper...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
CTO
SnapHop (snaphop.com)
(twitter) @agentgt (linkedin) http://www.linkedin.com/in/agentgt
(cell) 781-883-5182

[Jonathan Halterman]

On Thursday, March 14, 2013 5:16:19 PM UTC-7, Adam Gent wrote:

Jon,

Exactly what I want. I prefer the library setting the properties via
the contructor as it seems less disingenuous and more threadsafe
(given Java's memory model).
Curious: I know that Hibernate will even set `private final` variables
regardless of the `final`. Does Modelmapper do so likewise?

Yep, that's what I meant about overriding the object's security. It's not ideal, but it is necessary for some cases. For what it's worth, many libraries that construct and populate instances of user-defined classes do this. Spring and Guice are two more that come to mind.

I should mention that supporting @ConstructorProperties means I'd have to kill support for 1.5. I didn't realize how many people still use 1.5 until I initially didn't support it. I'll have to think about that one a bit more...