Orika vs. JMapper - how it works and speed difference - why?

I downloaded and tested these two mapping libraries. I wrote a program that has 100,000 iterations and displays beans of the same class:

public class IntBean { @JMap private int int1; @JMap private int int2; . . . @JMap private int int10; } 

Mappers are created BEFORE starting iterations:

 private JMapper jmapper = new JMapper(IntBean.class, IntBean.class); private MapperFactory orikaFactory = new DefaultMapperFactory.Builder().build(); private MapperFacade orikaFacade = null; orikaFactory.registerClassMap(orikaFactory.classMap(IntBean.class,IntBean.class).byDefault().toClassMap()); orikaFacade = orikaFactory.getMapperFacade(); 

What is at each iteration:

 this.orikaFacade.map(a1, a2); 

or

 a2 = (A) this.jmapper2.getDestination(a1); 

Manual display: 1 ms

Orika Display: 32 ms

Hand mapping: 6 ms BIG SPEED !!!

Bulldozer: 1140 ms

I know that Orika and Jmapper are different libraries from Google, and they use reflection differently than, for example, Dozer, which is much slower, they reflect the code generator somehow ..

I have 3 questions:

1) How do they work - when the code is generated during the maven build at runtime - every time I create a mapper in the code? Are they dynamically changing bytes of class code when I create mappers.?

2) Why is there such a difference in speed that I noticed? If you generate the code in some way, then why there are different results

3) Which library would you choose and why? Both have the same features? Why are both from Google? Why didn’t Google develop Orika and create Jmapper?

+7
java mapping orika
source share
3 answers

I am not familiar with Jmapper, so I will focus on Orika and Dozer

  • How do they work? Both of them work differently. Reflection bulldozer and Orika using bytecode generation. During maven build? Nothing happens, all this is done during work. Dozer accesses the fields through its get methods and sets the value in the target using setter methods. Orkia generates bytecode to do the work, as if you manually typed the card. It is slow on the first conversion and should be faster on each after that.

  • A bulldozer should always be about the same speed, relies on reflection. Orika, bytecode generation, 1st run should be much slower when generating display code.

  • Short answer, it depends. What are you trying to display? Dozer is very good when comparing from one type to another if the classes are roughly the same. It has nothing to do with Maps at all. Be prepared to write custom converter code if you have a map in the object

Orika is fantastic when displaying data between two objects of the same type. Some of its handling of List is a little strange when it will treat the list as a separate object, rather than a collection of separate objects. Again, be prepared to write code for this too.

None of them handles a large graph of objects very well; be prepared to write a lot of settings for this.

If you are going to do a lot of mapping in the application or mapping, which often needs to be changed. Write your own

+4
source share

JMapper is based on the Javassist structure, the power of this structure is the ability to apply enrichment, dynamic comparisons, multi-relational comparisons, inherited mapping and other functions without loss of performance.
All code is written at the design stage. The goal of jmapper is: ease of use with the efficiency of manual coding.

+1
source share

Japper

JMapper Framework is a java bean for java bean mapper, allows you to dynamically transfer data using annotations and / or XML. jmapper is not limited to generating code at runtime, it applies a number of optimizations that the developer does not do normally. With JMapper, we have all the benefits of dynamically matching static code performance with 0 memory consumption https://code.google.com/p/jmapper-framework/

Pros : 1. XML and annotations are available. 2. From 1 to N and from N to 1 relationships 3. Explicit conversions 4. Inherited configurations. 5. Performance is good compared to a bulldozer.

against : 1. Aggregation is achieved through Explicit transformations 2. Main documentation. 3. JMapper is still under development.

MapStruct : MapStruct is a compile-time code generator for bean mappings, which results in fast (without using reflection or similar), without dependencies and types of display code at runtime. http://mapstruct.org/

Pros : 1. Display through the interface. 2. Generation of a temporary compilation code, which leads to fast (without using reflection or the like). 3. Nested mappings for the source object. 4. Implicit type conversions, for example, between all primitive Java types (including their wrappers) and String, for example. between int and String or Boolean and String. 5. Custom cards. 6. Collecting cards is easy. 7. Exception handling. 8. Inverse mappings. 9. Good documentation and forums. 10. Performance is good compared to Jmapper and bulldozer.

against : 1. The properties of the target should not be nested. 2. For a backward comparison, he will need an additional comparison, or he needs to create a new comparison. 3. We can use manual code instead of MapStruct, and it gives better performance.

+1
source share

All Articles