Pitfalls and Solutions for Converting Java Beans to Maps

Background : In many business scenarios a Java Bean needs to be converted to a Map for further processing, but seemingly simple conversions often hide numerous traps.

1. JSON‑based conversion pitfalls

Using JSON frameworks like Fastjson, Gson or Jackson to serialize a bean and then deserialize it into a Map can cause type loss. For example, a Long field whose value fits into an Integer range becomes an Integer after conversion, and Date becomes a timestamp Long. The article provides Maven coordinates for Fastjson and a sample code snippet that demonstrates the problem and the resulting map output.

import com.alibaba.fastjson.JSON;
import com.alibaba.fastjson.TypeReference;
import java.util.Date;
import java.util.Map;

public class JsonDemo {
    public static void main(String[] args) {
        MockObject mockObject = new MockObject();
        mockObject.setAInteger(1);
        mockObject.setALong(2L);
        mockObject.setADate(new Date());
        mockObject.setADouble(3.4D);
        mockObject.setParent(3L);
        String json = JSON.toJSONString(mockObject);
        Map<String,Object> map = JSON.parseObject(json, new TypeReference<Map<String,Object>>(){});
        System.out.println(map);
    }
}

2. BeanMap property‑name errors

Both commons-beanutils and cglib based BeanMap suffer from incorrect property name extraction. The underlying java.beans.Introspector uses decapitalize, which mistakenly converts method names like getALong to aLong and also mishandles acronyms such as URL (converted to uRL). The article shows Maven coordinates, example code, and screenshots of the erroneous output.

import org.apache.commons.beanutils.BeanMap;
import third.fastjson.MockObject;
import java.util.Date;

public class BeanUtilsDemo {
    public static void main(String[] args) {
        MockObject mockObject = new MockObject();
        mockObject.setAInteger(1);
        mockObject.setALong(2L);
        mockObject.setADate(new Date());
        mockObject.setADouble(3.4D);
        mockObject.setParent(3L);
        BeanMap beanMap = new BeanMap(mockObject);
        System.out.println(beanMap);
    }
}

3. Solution using Dubbo PojoUtils

The article recommends Dubbo's PojoUtils.generalize method, which correctly preserves both types and property names. Maven coordinates for Dubbo are provided, along with a concise demo that prints the properly generalized map.

import org.apache.dubbo.common.utils.PojoUtils;
import third.fastjson.MockObject;
import java.util.Date;

public class DubboPojoDemo {
    public static void main(String[] args) {
        MockObject mockObject = new MockObject();
        mockObject.setAInteger(1);
        mockObject.setALong(2L);
        mockObject.setADate(new Date());
        mockObject.setADouble(3.4D);
        mockObject.setParent(3L);
        Object generalized = PojoUtils.generalize(mockObject);
        System.out.println(generalized);
    }
}

The core of PojoUtils.generalize iterates over bean getters, uses reflection to obtain property names via ReflectUtils.getPropertyNameFromBeanReadMethod, and recursively processes collections, arrays, and maps, ensuring accurate type conversion and property naming.

Conclusion : Converting Java Beans to Maps is fraught with pitfalls such as type loss and incorrect property name resolution. Developers should verify behavior with concrete demos, read source code, and prefer reliable utilities like Dubbo's PojoUtils to avoid these issues.