@ToString formatting 'language'.

[rzwitserloot]

This is the umbrella issue for any requests to improve or modify the way @ToString prints in some fashion.

The general notion would be to have a regex like pattern language to specify exactly what you want. Some examples, given:

package foo;
public class Test {
    String name;
    int age;
    int[] values;

    public String getSummary() { return "hello"; }")
}

1: new Test("Joe", 50, new int[] {5, 12, 14})
2: new Test(null, 50, new int[0]);
3: new Test(null, 50, null);

@ToString("<class>{<#name>: <#getSummary()>}")
1: Test{Joe: hello}
2,3: Test{null: hello}

@ToString("<fqn>{<#values: [a, b]>: <fieldNames: n1=v1 n2=v2>}")
1: foo.Test{[5, 12, 14]: name=Joe age=50}
2: foo.Test{[]: name=Joe age=50}
3: foo.Test{null: name=Joe age=50}

etcetera.

Concerns:

• Print classname, fully qualified classname, or nothing.
• Print all fields, vs all fields not explicitly called out
• Print the result of a no-args method.
• Specify how to print listy things (prefix/suffix/infix, and/or how to deal with an empty one)
• Specify alternate content in case of null.
• Print content indented, including properly indenting the content if it, itself, has newlines in it, to allow structured printing.

This issue supercedes #876 #1216 #1276 #918

Not sure if we actually want this; there's a lot to cover, toString() is a debugging aid (if it's something else, you're doing it wrong), and it feels like reinventing an entire programming language when you can just.. program your toString() method in java by.. just typing java code in the editor you're already in.

[askoning]

This issue also supercedes #256 #529 #1211

[gmathias]

I don't think hideNulls (#256 #529 #1211) should be covered (only) by pattern. The pattern is for formatting while hideNulls is for filtering content. Also it would be over-complicated to write a pattern just to say "hide nulls". Please keep the boolean flag separated from the pattern.

[jefferyyuan]

a separate boolean flag for hideNulls is very useful.

• This is the most wanted feature about ToString annotation
• It's much easier to use for client
• It's much easier to implement

[wheredevel]

Is there a way of weaving methods in Lombok? (Traits...?) (Mixins...?)

Why do I ask under this issue at all:
Because I have a method called toJson().
The implementation is something like this:

protected String toJson() {
	return new ObjectMapper().writeValueAsString(this);
}

Now, the only way to have it in my classes of interest - is to inherit from some class implementing it.
And this is ugly. Not a Lombok way!!! Lombok does Object. ;)
So, instead, I would prefer a way to weave this implementation into classes of interest.

Finally, I'd like to use it as a toString() replacement.
For that I would do something like @ToString(delegate=toJson) - which should result in something like:

@Override
public String toString() {
	return toJson();
}

And this is my suggestion as to how to solve the toString() formatting issue discussed here: in an imperative, instead of a declarative way.

What do you think?

[gmathias]

It's disappointing to not have even a reply. Lombok made Java great again, please continue to improve it.
Please reopen one of the hideNulls issue ! Or explain why this unrealistic issue supercedes the easy-to-implement really-useful hideNulls issue) !

[Maaartinus]

It's disappointing to not have even a reply.

I'm not a project owner, but my answer may be better than nothing.

---

Lombok doesn't support traits. There's @Delegate and @ExtensionMethod. The latter could help. It add s no methods, but let's you write yourObject.toJson().

@ToString(delegate=toJson)

This could be a nice feature. It may be better to allow placing @ToString (or @ToString.Delegate) on a method (avoiding stringly-typed arguments). This obviously won't work with @ExtensionMethod.

But maybe you can define an @ExtensionMethod for toString() directly? No idea if it takes precedence over an inherited method (I guess so, as lombok knows nothing about inheritance).

And this is my suggestion as to how to solve the toString() formatting issue discussed here: in an imperative, instead of a declarative way.

This is similar in spirit to my proposal #1393.