Original comment posted by ray.j.greenwell on 2010-09-17 at 10:27 PM

That can also be useful, but:

• Sometimes it's too much information. You might just want print a summary of important fields.
• The reflection methods are defined as not returning the Fields in any particular order (although in practice I find it to be in declaration order). In any case, you may want to output more important fields prior to less important ones.
• Finally, a reflection-based toStringer may not be able to access every field, nor can it print computed values.

In reality it's far more convenient to customize the output rather than do a full TMI dump, but sometimes a reflection-based output is useful for simpler classes.

Original comment posted by boppenheim@google.com on 2010-09-23 at 04:32 AM

It's definitely annoying to have to modify the tostringhelper call every time you add/change/delete a field (equals and hashCode too for that matter). I tend to agree with Ray about the downfalls though. I also would be interested to see what the performance implications of using reflection would be. I understand it's not as bad as it used to be though.

I wonder if annotations would help make the reflection-based approach more viable? @ToStringField and/or @ToStringField("fooBar") and/or @NoToString? On the other hand, this might not be worth the extra code noise.

Original comment posted by ian.b.robertson on 2010-10-04 at 08:48 PM

There are some annotation-driven solutions out there. Project Lombok will use annotation processing to generate the methods. Pojomatic doesn't require any special compile-time processing, but uses reflection. Reflection definitely is slower, but for most cases is still plenty fast.

Original comment posted by j...@nwsnet.de on 2010-10-05 at 10:26 AM

What about classes which refer to each other via fields? When all fields are considered by such a dynamic toString() helper, wouldn't that result in possibly infinite recursion when trying to call toString() on its values?

I recall having a similar/related issue (though the toString() implementations explicitly included such fields).

Original comment posted by kevinb@google.com on 2011-03-19 at 03:13 PM

I really don't want to go here. These utilities are what they are; they're programmatic, not reflective, and I'm comfortable with saying that whatever provides the reflective functionality will just be something else. Or, if we provide anything, it will be in a com.google.common.reflect package and will handle much more than just toString.

Status: WontFix

Original comment posted by SeanPFloyd on 2011-03-21 at 11:25 AM

Kevin: com.google.common.reflect sounds good. Are there any plans in that direction?

Up. This functionality might be very useful for POJOs.
Almost 5 years gone. Since previous decision. Maybe you want change it?

Our general advice for people writing toString by hand is to use AutoValue.