Shulou(Shulou.com)06/02 Report--

This article mainly introduces "why not recommend using BeanUtils attribute conversion tool". In daily operation, I believe that many people have doubts about why they do not recommend using BeanUtils attribute conversion tool. Xiaobian consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the question of "Why not recommend using BeanUtils attribute conversion tool". Next, please follow the editor to study!

The main reasons for not recommending are:

Some attribute copying tools have poor performance.

Some attribute copy tools have "BUG"

There are some hidden dangers in using the attribute copy tool (which will be discussed in a later example)

Example

First of all, the company has encountered a real case in which the BeanUtils of the commons package has poor attribute copy performance, and then the colleague replaced the BeanUtils performance of Spring with much better performance. If you are interested, you can use the performance testing framework or benchmark framework to compare, but there is no comparison here.

Next, let's take a look at the problem with the attribute copy of Spring's BeanUtils:

Import lombok.Data

Import java.util.List

@ Data

Public class A {

Private String name

Private List ids

}

@ Data

Public class B {

Private String name

Private List ids

}

Import org.springframework.beans.BeanUtils

Import java.util.Arrays

Public class BeanUtilDemo {

Public static void main (String [] args) {

A first = new A ()

First.setName ("demo")

First.setIds (Arrays.asList (1,2,3))

B second = new B ()

BeanUtils.copyProperties (first, second)

For (String each: second.getIds ()) {/ / Type conversion exception

System.out.println (each)

}

}

}

When you run the above example, a type conversion exception occurs.

As you can see from the breakpoint, the ids in the second object of type B is still of type Integer after the attribute is copied:

If you do not convert to a string, print directly and will not report an error.

You will encounter similar problems with CGlib without defining Converter:

Import org.easymock.cglib.beans.BeanCopier

Import java.util.Arrays

Public class BeanUtilDemo {

Public static void main (String [] args) {

A first = new A ()

First.setName ("demo")

First.setIds (Arrays.asList (1,2,3))

B second = new B ()

Final BeanCopier beanCopier = BeanCopier.create (A.class, B.class, false)

BeanCopier.copy (first,second,null)

For (String each: second.getIds ()) {/ / Type conversion exception

System.out.println (each)

}

}

}

Again, the problem is exposed at run time.

Let's take a look at mapstruct:

Import org.mapstruct.Mapper

Import org.mapstruct.factory.Mappers

@ Mapper

Public interface Converter {

Converter INSTANCE = Mappers.getMapper (Converter.class)

B aToB (A car)

}

Import java.util.Arrays

Public class BeanUtilDemo {

Public static void main (String [] args) {

A first = new A ()

First.setName ("demo")

First.setIds (Arrays.asList (1,2,3))

B second = Converter.INSTANCE.aToB (first)

For (String each: second.getIds ()) {/ / normal

System.out.println (each)

}

}

}

You can successfully convert List in A to List in B.

Let's take a look at the compiled Converter implementation class:

Import java.util.ArrayList

Import java.util.List

Import javax.annotation.Generated

Import org.springframework.stereotype.Component

@ Generated (

Value = "org.mapstruct.ap.MappingProcessor"

Comments = "version: 1.3.1.Final, compiler: javac, environment: Java 1.8.0U202 (Oracle Corporation)"

)

@ Component

Public class ConverterImpl implements Converter {

@ Override

Public B aToB (A car) {

If (car = = null) {

Return null

}

B b = new B ()

B.setName (car.getName ())

B.setIds (integerListToStringList (car.getIds ()))

Return b

}

Protected List integerListToStringList (List list) {

If (list = = null) {

Return null

}

List list1 = new ArrayList (list.size ())

For (Integer integer: list) {

List1.add (String.valueOf (integer))

}

Return list1

}

}

Automatically helps us with the conversion, and we may not realize that the types are not consistent.

If we add a String number attribute to class An and a Long number attribute to class B, we use mapstruect to report .NumberFormatException when number is set to a non-numeric type.

@ Override

Public B aToB (A car) {

If (car = = null) {

Return null

}

B b = new B ()

B.setName (car.getName ())

If (car.getNumber ()! = null) {/ / the problem is here

B.setNumber (Long.parseLong (car.getNumber ()))

}

B.setIds (integerListToStringList (car.getIds ()))

Return b

}

Using cglib defaults to not mapping the number attribute, and number in B is null.

If you define the converter manually, use the IDEA plug-in (such as generateO2O) to convert automatically:

Public final class A2BConverter {

Public static B from (A first) {

B b = new B ()

B.setName (first.getName ())

B.setIds (first.getIds ())

Return b

}

}

This problem can be found very clearly during the coding phase:

At this point, the study on "Why not recommend the use of BeanUtils property conversion tool" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.