Add toString method for an easier debugging

[peterjurkovic]

Would be nice to have toString() methods across the lib

[judy2k]

This is definitely something we need to get better at.

[cr0wst]

I'm preferential to ReflectionToStringBuilder.toString. I know reflection can add a bit of overhead, but ideally toString is only being used for debugging output.

I also like json reflection using either Gson or Jackson. The downside with Jackson is you have to catch the exception:

@Override
public String toString() {
    try {
        return new ObjectMapper().writerWithDefaultPrettyPrinter().writeValueAsString(this);
    } catch (JsonProcessingException jpe) {
        // do nothing we're falling back
    }
    return ReflectionToStringBuilder.reflectionToString(this);
}

Edit: I should add that ObjectMapper is thread safe and could be used statically to prevent multiple instantiation. Even if there was a risk of deadlocking, I'm going under the assumption toString would still be done for debugging purposes.

Something like (I'm really bad at naming things):

public class ToStringUtil {
    private static final ObjectMapper OBJECT_MAPPER = new ObjectMapper();

    public static String reflectionToJson(Object object) {
        try {
            return OBJECT_MAPPER.writerWithDefaultPrettyPrinter().writeValueAsString(object);
        } catch (JsonProcessingException jpe) {
            // do nothing we're falling back
        }
        return ReflectionToStringBuilder.reflectionToString(object);
    }
}
// Usage:
@Override
public String toString() {
    return ToStringUtil.reflectionToJson(this);
 }

[michel-zimmer]

Have you considered adding Lombok to this project? This would also be a nice option not just for toString, but also as a reduction of boiler plate code for equals and hashCode and possibly more like constructors and so on. (Unless you do not want this, I'll provide a PR as part of the Hacktoberfest so that you can get an idea how this would look like.)

[michel-zimmer]

Feel free to comment on my PR (linked above)

[yallen011]

Yes, I was actually looking into adding Lombok and then completely forgot about it. This looks good. Would you like to continue refactoring this for the rest of the codebase? If so, I could assign this issue to you for you to continue working on it.

[michel-zimmer]

Sure, I can do that. Is there a way to test this including the JSON de-/serialization? That way I could possibly simplify the code a lot. (Otherwise I don't feel confident enough, because I could break something.)

[yallen011]

We have JUnit tests you can use to make sure existing functionality still works when you change the code. Feel free to add any unit tests you feel you need to add if you don't think the existing test will suffice. Tests are located src/test folder. We use gradle so to run the test you can run ./gradlew build (using the wrapper on a mac) and it will build the code and run the tests or you can do ./gradlew test. If you are running on a windows machine, that command is gradlew.bat build and gradlew.bat test. Let me know if you have any more questions. I am here to help.

[michel-zimmer]

OK, could you maybe merge the PR? I'd like to build on top of that one, but the PR has been unlinked from my fork and I cannot add new commits.

[SMadani]

Given that the repo has evolved significantly, there are no plans to add Lombok or merge the PR at the moment, but adding toString(), equals(Object) and hashCode() are on the roadmap. The aim is to have every public data model class (i.e. requests and responses) implement these in a standardised manner.

[SMadani]

Done in #508.