search

maidh91 / guava-libraries

Automatically exported from code.google.com/p/guava-libraries
Apache License 2.0
0 stars 0 forks source link

toString helper using reflection #422

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Did you consider to implement a toString helper using the Java Reflection API? 
A similar function is provided by Apache's commons-lang [1].

[1] 
http://commons.apache.org/lang/api-2.5/org/apache/commons/lang/builder/ToStringB
uilder.html#reflectionToString(java.lang.Object)

Original issue reported on code.google.com by Simon.Le...@gmail.com on 17 Sep 2010 at 7:35

GoogleCodeExporter commented 9 years ago 
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 by ray.j.gr...@gmail.com on 17 Sep 2010 at 10:27

GoogleCodeExporter commented 9 years ago 
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 by boppenh...@google.com on 23 Sep 2010 at 4:32

GoogleCodeExporter commented 9 years ago 
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 by ian.b.ro...@gmail.com on 4 Oct 2010 at 8:48

GoogleCodeExporter commented 9 years ago 
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 by j...@nwsnet.de on 5 Oct 2010 at 10:26

GoogleCodeExporter commented 9 years ago 
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.

Original comment by kevinb@google.com on 19 Mar 2011 at 3:13

GoogleCodeExporter commented 9 years ago 
Kevin: com.google.common.reflect sounds good. Are there any plans in that 
direction?

Original comment by SeanPFl...@googlemail.com on 21 Mar 2011 at 11:25

GoogleCodeExporter commented 9 years ago 
This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09