How to copy bean properties with a single line of code
This article shows how to copy multiple properties from one bean to another with a single line of code, even if the property names in the source and target beans are different.
Copying properties from one bean is quite common especially if you are working with a lot of POJOs, for example working with JAXB objects. Lets walk through the following example where we want to copy all properties from the User object -> SystemUser object
Example: source and target objects
// source object that we want to copy the properties from
public class User {
private String first;
private String last;
private String address1;
private String city;
private String state;
private String zip;
private String phone;
// getters and setters
// ...
}
// target object that we want to copy the properties to
public class SystemUser {
private String firstName;
private String lastName;
private String phone;
private String addressLine1;
private String addressLine2;
private String city;
private String state;
private String zip;
// getters and setters
// ...
}
Example continued: Preparing the objects
// initializing the source object with example values
User user = new User();
user.setFirst("John");
user.setLast("Smith");
user.setAddress1("555 Lincoln St");
user.setCity("Washington");
user.setState("DC");
user.setZip("00000");
user.setPhone("555-555-5555");
// creating an empty target object
SystemUser systemUser = new SystemUser();
Approach 1: Traditional code for copying properties
systemUser.setFirstName(user.getFirst()); systemUser.setLastName(user.getLast()); systemUser.setPhone(user.getPhone()); systemUser.setAddressLine1(user.getAddress1()); systemUser.setAddressLine2(user.getAddress2()); systemUser.setCity(user.getCity()); systemUser.setState(user.getState()); systemUser.setZipcode(user.getZip());
Approach 2: Single line code for copying properties
copyProperties(user, systemUser, "first firstName", "last lastName", "phone",
"address1 addressLine1", "address2 addressLine2", "city", "state", "zip zipcode");
Parameters
- user – the source object
- systemUser – the target object
- first firstName – indicates that the “first” property of the source object should be copied to the “firstName” property of the target object
- last lastName – indicates that the “last” property of the source object should be copied to the “lastName” property of the target object
- phone – indicates that the “phone” property of the source object should be copied to the “phone” property of the target object
- …. and so on
The underlying code uses Apache Commons BeanUtils code to copy the property value from the source to the destination.
You can download the copyProperties code from Google Code. Simply copy the code to your project. The code requires apache BeanUtils. If you are using maven, you can get BeanUtils by adding the following to your pom.xml
<!-- for maven only, add this to your pom to get BeanUtils, needed by the copyProperties code --> <dependency> <groupId>commons-beanutils</groupId> <artifactId>commons-beanutils</artifactId> <version>1.8.3</version> </dependency>
References
Related posts:
Nice and simple tips.thanks!!
Or you could use Dozer (http://dozer.sourceforge.net/), which might be too heavyweight in this situation, but seems like it would be unbelievably valuable if you need to convert large, deeply nested POJOs from one form to another (e.g. Exposed Web Service POJO -> Internal Hibernate POJO).
nice lesson,thanks
Nice, if you like to create a maintainance nightmare.
Nice tip, but the “commons-beanutils” does a shallow copy only. It fails when deep copies are required
Refactoring property names or adding new properties to your beans becomes a funny task with this solution
Nice. Any benchmark on the performance?
Nice article about a common problem we all face everyday. The Apache utils are indeed very powerful in handling this. Still I wouldn’t recommend using this technique because, as Joerg Wassmer said, it will become a maintenance nightmare. I still prefer using the traditional technique, or modeling my classes(if possible of course) to make use of interfaces/inheritance where possible to make the copyProperties work without the field parameters.
This approach has several flaws:
- It prevents compile-time checks, which is almost always a bad idea.
- It relies heavily on reflection, which means a serious impact on performances.
- It does everything on one very long line, and is barely readable. The “trick” to map from one property name to another is especially awful.
IMHO, no programmer should use those methods, except in the following cases:
- The names of the properties to copy are not known at compile-time and obtained at runtime. Even then, there are better alternatives.
- Quick prototyping (e.g. for a POC or a use-today-delete-tomorrow program).
you suggestion make code unmanageable.Not a good idea
I understand the pros and cons or static vs dynamic typing. Putting method names in string constants does not help your IDE when you are refactoring method names (although you could catch it with a unit test). Also, reflection will not give you a better performance as compared to statically typed code.
I wrote this program for some small throw away program, which had a small shelf-life where maintainability or performance did not matter. The point of writing this method was an attempt to avoid typing lengthy getter-setter copy statements for doing something trivial.
It would be nice if we don’t have to include an external lib
.
If I have to use lib, I will use either Dozer (dozer.sf.net) or ObjectAssembler (objectassembler.googlecode.com) for such tasks
I meant simple-object-assembler.googlecode.com