Tkit Mapping

[maybeec]

Discuss on harvesting Tkit Mapping.
What does it provide on top of Orika / MapStruct?
Is MapStruct the better solution for Quarkus as it does not rely on any reflection?

[hohwille]

We have this API:
https://github.com/devonfw/devon4j/blob/master/modules/beanmapping/src/main/java/com/devonfw/module/beanmapping/common/api/BeanMapper.java

IMHO this is the most convenient and simple API and we would like to keep it instead of breaking it.
For GraalVM it is possible to provide ATC generation either using existing solutions (MapStruct, Orika, etc.) or even by implementing your own generator.

[hohwille]

I do not like the approach of MapStruct to create an own API for each Entity/Transferobject pair as this is pointless boilerplate code.

[matus-m]

We have actually ruled out Orika, Dozer, beanmapper because of reflection/black box model, when we did our bean mapper eval few years back :)
For simple cases where both sides have identical shape I might save a few lines of code with implicit bean mapper, but if I got it right, I anyhow have to register custom classmappers/field mappings as soon as the two sides differ(A.total -> B.totalValue. In our real world use where we have most of the time strict API definitions with complex object hierarchies we found Mapstruct super useful for the following reasons:

• its much faster at runtime - uses plain getters setters benchmark
• we can inspect/debug the mapping code in edge cases just like we would our own code, yet its inobtrusive in target/generated-sources
• catches whole class of errors at compile which reflection mappers would report at runtime(non matching fields for example`
• also optionally report missing mappings at compile time(e.g. I added field to A and forgot to add to B)
• allows injection(resulting impl classes are beans) so you can can do more advanced things with it while still being safe
• more declarative style(subjective preference)

example error case that is reported by mapstruct at compile time, vs reflection mapper at runtime

example injection usecase

In any case, although we use mapstruct exclusively in dozens of projects and are happy with it, we have decided not bundle any beanmapper specific features with our new fw libs(we recommend mapstruct in our guides) and leave the choice to app developers as the bean mapper has almost no coupling to app framework anyhow.
So they might in the end mix and match libraries based on experience/preference. So the orika based bean mapper can happily stay as an option(the only integration with the framework would anyhow be just exposure as CDI bean = few lines of code).

[maybeec]

when I see the standard mapping configuration which you show here and I compare them to Orika, it looks exactly the same.
@hohwille, I remembered, that you said, it's completely different and cannot exchanged behind the MapperFacade implemented at devonfw. Could we anyhow maybe do it and leave some more complex features open to be implemented aside from our facade?
Just wondering as even with the step to Quarkus MapStruct seems to me more and more the better choice.

[hohwille]

The idea of BeanMapper in devonfw is that you have a minimal generic API and shim for bean mapping.
This allows to abstract from the underlying implementation. We have started with dozer - it was too slow and therefore we changed to Orika that generates very efficient code. It is fully fine also to use MapStruct or whatever below this minimal API.

I also see that both sides are somewhat biased what is kind of natural. So if we can have a bean mapper implementation also for MapStruct it would be a win-win. I once talked to the developers of MapStruct and they told me that MapStruct generates an Mapper class for each pair of convertable objects that has an "indivudal API" and therefore it can not be interchangeable like Orika or Dozer, etc. And we managed to change that in running projects with minimal effort and without any code-change in the buisiness code (ony some config code had to be changed).

Maybe that has changed meanwhile as our evaluation is several years old.
The same IMHO applies for @yntelectual args about performance. These performance statistic is totaly old and not correct anymore. Further, we want to be cloud-native and generate the app with graalVM. Therefore we should compare performance of the native binaries.
Anyhow, if we manage to abstract via BeanMapper API people can pick and choose the implementation according to different requirements where performance is just one option.

And BTW: We try to enforce that Getters and Setters of mappable properties are exactly the same between Entity and transferobject (ETO = Entity Transfer Object in devonfw, DTO = Data Transfer Object in TKit). So why do I need to differ A.total -> B.totalValue? Anyhow this is fine if it is an edge case (e.g. to keep API compatible why for DDD people insist on renaming something in data-model/entity).

[matus-m]

And BTW: We try to enforce that Getters and Setters of mappable properties are exactly the same between Entity and transferobject (ETO = Entity Transfer Object in devonfw, DTO = Data Transfer Object in TKit). So why do I need to differ A.total -> B.totalValue? Anyhow this is fine if it is an edge case (e.g. to keep API compatible why for DDD people insist on renaming something in data-model/entity).

This is fairly common case e.g. when you implement an API you cant control (TM forum standards for instance, any 3rd party API...) and you don't want to adjust your data model naming to fit the API naming or when you have fixed public API and evolve your JPA model - We cant break the API as there are clients that consume it, but we may do arbitrary changes to our data layer, split tables, introduce completely different storage provider etc. In this case the mapping layer will allow us to adjust to this change without any influence on the API model.

Regarding choice of mapping framework: my suggestion was simply to try to make the Devonfw as agnostic of Bean Mapping FW as possible, so that developers can pick the preferred provider(if required at all) and to state our good experience with Mapstruct over the years. If Orika works in GraalVM as well, then we could simply provide examples of both in some demo/ref project with brief description of differences.