We use the ToStringBuilder.reflectionToString() methods in our toString() objects. We had no problems like this in a production environment. Of course, we rarely use the toString() method.
We also use BeanUtils.describe() , but for a different purpose. BeanUtils uses a PropertyUtilsBean , which stores the beans beans internal cache for which it performed an introspection. It would seem that this will give him a performance advantage over another, but will focus on the source of reflectionToString a bit, and it seems that since he ultimately relies on the java.lang.Class implementation, caching also plays there.
It either looks like a viable choice, but BeanUtils.describe() will return a property map where reflectionToString will return a formatted string. I think it depends on what you want to do with the exit.
I would suggest that if your application is highly dependent on calling toString() on your objects, using a specific implementation might be more useful.
jt.
source share