Lombok: Feature request: @ToString allows skipping null-value fields

[chriswilty]

It would be nice if I could skip null-valued fields in the generated toString(), e.g. with

@ToString(excludeNulls = true)
class MyClass { ... }

As Optionals are not supported by lombok, I may have one or more fields that are nullable in my DTO, and which do not need to be set during construction.

This is a nice-to-have; it's not the end of the world to need to copy the generated toString and add in my null-exclusion logic, nor indeed to see "fieldName=null" in the toString output, as I only use it for logging. If it's not an easy win, don't worry about it :grin:

[mohasaid]

I could work on it, let's see if someone confirms me.

[Maaartinus]

@chriswilty This issue is a duplicate of quite a few -- IMHO erroneously -- closed issues, as stated in this comment.

@mohasaid The idea has been discussed since ages and implementing it without helper methods is said to be a lot of work. And it's getting more complicated as new features get added, like using methods rather than fields only.

It'd make sense to add skipNulls as an option to the nested annotation @ToString.Include, too.

Anyway, you'd better await an OK by the project owners.

---

PS: There are related feature requests like skipping empty fields, but it's unclear what "empty" means in general. For a field like private SomeType amIEmpty, it's unclear, how to test it. SomeType could be a descendant of Collection to be tested with amIEmpty.isEmpty() (or amIEmpty.size() == 0) or an implementation of CharSequence to be tested with amIEmpty.length() == 0. Actually, it could be both.

The only good news is that it can't be an array. This can of worms should probable be left closed.

[chriswilty]

@Maaartinus Thanks for the input, and the link to #1297, which I'd managed to miss.

I feel that issue has exploded a bit with all the "oh, and how about if it did this..." issues linked. In contrast, the concept of nulls being a special case is already part of lombok (@NonNull and the @-ArgsConstructors) which is why I felt it would be a natural addition.

I deliberately didn't include a request for @ToString.(In|Ex)clude because I foresaw that it could be a springboard for all sorts of other requests to expand the functionality of those, however, for the sake of completion and consistency it might make sense to augment those also. I'm not sure that it makes sense to have skipNulls as an option to @ToString.Include as skipping is an exclusion; probably something like @ToString.Include(onlyNonNull = true).

Anyhow, as stated it's not a big problem to need to write my own toString, so I won't be upset if this issue is closed also :)

[Maaartinus]

@chriswilty

I'm not sure that it makes sense to have skipNulls as an option to @ToString.Include

My only problem with this is that it mayn't be very useful. Quite often, you want to include (or exclude) some fields, quite often you want to exclude all nulls, and probably only rarely you want to include some field unconditionally and others only when not null.

as skipping is an exclusion; probably something like @ToString.Include(onlyNonNull = true).

IMHO the name should be the same as @Whatever.Include is (a sort of) the per-field variant of @Whatever. It just has double duty: Ensure that the field gets considered AND optionally override options. While some options make no sense in one place (e.g., callSuper or rank), others do. Don't let English grammar details take over logic (see SQL or Javabeans for where it leads to).

I'd read @*.Include(skipNull = true) like "include this field, but skip it if null". It's still an inclusion, it's just conditional. ;) More importantly: It's an override for the equally-named option on the master annotation.

IMHO @*.Exclude should never get any options. In this case, conditional exclusion is tempting, but conditional exclusion is the same thing as conditional inclusion, just with the inverse condition. This would lead to needless ambiguities.

[thorvx]

any news about this request?

[remigiusv]

we expect this feature to be prioritised

[randakar]

Based on what?

On Fri, Jul 19, 2019 at 7:49 AM remigiusv [e-mail] wrote:

we expect this feature to be prioritised

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1752?email_source=notifications&email_token=AABIERLIY2I7ONEEMNIRF4DQAFIYLA5CNFSM4FICT4TKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2KUS6A#issuecomment-513100152,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABIEROKSQ75GCM7TAHGLDLQAFIYLANCNFSM4FICT4TA
.

--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven

[remigiusv]

toString implementation needs an option of printing only non null members of the class we annotate. Badly its needed for better logging.

[randakar]

If you have so many fields that you desperately need filters in your
toString implementation your class is doing too much at once, imho.

On Tue, Jul 23, 2019 at 6:57 AM remigiusv [e-mail] wrote:

toString implementation needs an option of printing only non null members
of the class we annotate. Badly its needed for better logging.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1752?email_source=notifications&email_token=AABIERNAPGW56UOPAYNBVVLQA2FVBA5CNFSM4FICT4TKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2R5P4I#issuecomment-514054129,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABIERPWHWFCYLUEFC4I57LQA2FVBANCNFSM4FICT4TA
.

--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven

[valentinbrasov]

Any progress on this? And by "this" I mean allowing something like @ToString(excludeNulls = true) at the top level (class level), not something on each individual field. I am working on a project and we are using lombok, except the @ToString for this very reason, because it would pollute the logs by listing null fields. So as it is (without the capability to skip null fields), the @ToString is useless to us.

[rzwitserloot]

telling an open source dev 'this needs a higher priority' is a great way to cause demotivation. Not fair to the great contributors we do have, but, @remigiusv – you need to work on your manners. I don't work for you! If I could write this feature such that it wouldn't work for just you, I'd do it. Fortunately, open source doesn't work that way, but, cripes. Way to be a downer.

Not a high priority right now. The problem with adding 'just this feature' without considering the greater scope is that if we DO eventually get around to rethinking how to make ToString more configurable, perhaps we then realize that we have to deprecate this feature, or we now have two ways to accomplish the same thing which is a needless raising of learning curve and opening the door to style debates.

[rmannibucau]

+1 for this feature, I can see some cases it is undesired but for all DTO (in particular in microservice erea) it is really a code and time saver to be able to skip nulls (and lombok is literally about it right?).

[rspilker]

What about other default values? Like 0, 0.0, false, '\0'? What about the empty string? Or even skipping every value that has the same value as the field initializer expression, or even take constructors into account?

What makes null so special that it deserves explicit and special handling?

[rmannibucau]

@rspilker the fact it can be not initialized - which is not true for primitives. For example in a DTO, adding a "integer" (functionally) you can choose to make it appearing or not by using Integer or int so a natural toString implementation would be enabled to follow that. That said if you go the @ToString.SkipIfEquals("...") path I'm more than happy with it too while null can have a "on class" toggle (= good default) since it is still the most common in most application (even if I agree some only use primitive but it is not mainstream at all). Finally, empty string and initializer cases don't make sense for me since it is about representing the values. Only specifity is: do you keep nulls or not in the reprensentation.

I guess we can take inspiration from most common JSON setups there, generally null are ignored and you can force them to be shown. All other settings are rarely used (for "tostring" case) so I guess only supporting null is a huge step forward and that if can be refined for primitives later if needed but i'm not sure primitive really pollute the output as much as strings/objects in practise.