Omit null values in @ToString annotation

[Leonard Wolters]

It would be very nice to have an additional parameter the in @ToString annotation for omitting null values.
This way you can restrict your output.

Example:

@ToString(omitNullValues=true)
public class Foo {
      private Integer a;
      private int b = 10;
}

would result in: 'Foo(b=10)'

[Fabrizio Giudici]

On Thu, 19 Sep 2013 10:25:03 +0200, Leonard Wolters <lwol...@gmail.com>
wrote:

It makes sense.


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[Leonard Wolters]

If desirable I can implement this. Just let me know.

Leonard

PS: Currently figuring out how Lombok affects java debugging (line numbers etc).
Since source code is automatically injected, this affects line numbers etc.

Op donderdag 19 september 2013 10:57:28 UTC+2 schreef Fabrizio Giudici:

[Reinier Zwitserloot]

We started doing this as a really quick to implement feature and it turns out it would take very slightly longer than that so we dropped it because we had more pressing  things to do (JDK8 support, and now, devoxx presentation). We'll pick this up sooner rather than later, though.

[Reinier Zwitserloot]

All your actually written code keeps its line number, and generated code will pick one of 3 line numbers depending on what makes eclipse not blow a gasket / have useful behaviours when selecting 'find callers' and such:

* 0

* The position of the thing that is responsible. (The position of a getter method including everything that is a part of it, is all set to the @Getter annotation, or the @Data annotation)

* The whitespace in between where the thing would have been handwritten if you had handwritten it.

It's usually the second one.

In javac we're a little bit more cavalier about positions; we should probably be more consistent about picking the second option.

If you use delombok, all bets are off of course, we can't avoid that.

[Leonard Wolters]

Thanks,

Good luck with Devvox,

Leonard

--
You received this message because you are subscribed to a topic in the Google Groups "Project Lombok" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/project-lombok/9on7mFH3z34/unsubscribe.
To unsubscribe from this group and all its topics, send an email to project-lombo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Erik]

I would love it if you guys could get this feature in.  This is the one thing I've always wished @ToString had.

I have a lot of DDOs (dumb data objects) with @Data and usually most of the fields are null.  I'd love a way to print out just the set fields, as it's really distracting to dig through all the ", field=null" text looking for it.

Thanks,

-Erik

[Reinier Zwitserloot]

I'll have a look at putting this on my personal todo list. It sounds trivial but it totally isn't; we can't loop over variables, so we have to change the generated boilerplate from this:

return "ClassName(foo = " + this.getFoo() + ", bar = " + this.getBar() + ")";

into:

Object $foo = this.getFoo();

Object $bar = this.getBar();

StringBuilder sb = new StringBuilder;

sb.append("ClassName(");

boolean first = true;

if ($foo != null) {

    if (!first) sb.append(", ");

    first = false;

    sb.append("foo = ");

    sb.append(foo);

}

if ($bar != null) {

    if (!first) sb.append(", ");

    first = false;

    sb.append("bar = ");

    sb.append(bar);

}

sb.append(")");

return sb.toString();

yeah, so, er, that's quite a bit of work to set that all up right. So, doable, sure, just, lots of work, I need to find some time. We can't create convenience methods because those would show up in your autocomplete etc and just be very confusing.

[Martin Grajcar]

It was you who mentioned a flag for using Guava: https://groups.google.com/d/msg/project-lombok/1C5vjPT6jro/-EARPnPS3BkJ. Something like

return Objects.toStringHelper(this).omitNullValues()

    .add("foo", getFoo()).add("bar", getBar()).toString();

would be much shorter (and much more readable when delomboked). I wonder if there are any users of Lombok avoiding Guava.

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.

[Reinier Zwitserloot]

Using a non ast transform based toString generator means reflection is involved which has bad connotations. For example, that does not work on GWT. We aren't going to add a dep on guava just to avoid an hour or two of busywork :P

[Fabrizio Giudici]

On Thu, 09 Jan 2014 15:50:14 +0100, Reinier Zwitserloot
<rei...@zwitserloot.com> wrote:

> Using a non ast transform based toString generator means reflection is
> involved which has bad connotations. For example, that does not work on
> GWT. We aren't going to add a dep on guava just to avoid an hour or two
> of
> busywork :P

I personally use Guava, but some customers use Lombok and not Guava. In
any case it would be surprising for many if a "core operation" required a
library (unlike @Slf4j for which it's obvious that one needs the library).

[Martin Grajcar]

On Thu, Jan 9, 2014 at 3:50 PM, Reinier Zwitserloot <rei...@zwitserloot.com> wrote:

Using a non ast transform based toString generator means reflection is involved which has bad connotations.

Reflection? I'm sure I wasn't proposing anything reflection-based, just replacing StringBuilder by ToStringHelper.

For example, that does not work on GWT.

I haven't tried, but com.google.common.base.Objects is marked @GwtCompatible. It's nothing but the convenience method you can't create.

We aren't going to add a dep on guava just to avoid an hour or two of busywork :P

I see.

[Reinier Zwitserloot]

I misunderstood what ToStringHelper does; it's not reflection based. Still, the dependency is a bit annoying. If we do this, we'll do it right and do it without an external dep.

[Erik]

It's been almost 2 years since this discussion.  Any chance of getting it in now?

I definitely understand the desire to avoid a new dependency on Guava, but surely the couple dozen lines of code to join non-null (or better: non-default) fields isn't incredibly hard to write.  If it's "just an hour or two of busywork" that busywork can be written once inside Lombok rather than dozens of times by each of its users.  That's the key value of Lombok itself, isn't it?

For a point of comparison, Jackson's

@JsonInclude(Include.NON_DEFAULT)

is what I'd like to see @ToString offer:

http://fasterxml.github.io/jackson-annotations/javadoc/2.0.5/com/fasterxml/jackson/annotation/JsonInclude.Include.html#NON_DEFAULT

-Erik

[Martin Grajcar]

On Thu, Nov 26, 2015 at 1:08 AM, Erik <eebuc...@gmail.com> wrote:

It's been almost 2 years since this discussion.  Any chance of getting it in now?

I definitely understand the desire to avoid a new dependency on Guava, but surely the couple dozen lines of code to join non-null (or better: non-default) fields isn't incredibly hard to write.  If it's "just an hour or two of busywork" that busywork can be written once inside Lombok rather than dozens of times by each of its users.  That's the key value of Lombok itself, isn't it?

+1

I guess, someone (e.g., me) could contribute this. It should be rather easy, even with Eclipse-perverted AST.

 

For a point of comparison, Jackson's

@JsonInclude(Include.NON_DEFAULT)

is what I'd like to see @ToString offer:

http://fasterxml.github.io/jackson-annotations/javadoc/2.0.5/com/fasterxml/jackson/annotation/JsonInclude.Include.html#NON_DEFAULT

This could be rather hard, es you'd have to determine the default value, which may get arbitrarily complicated or impossible (private int x = new Random(123).nextInt();). Jackson most probably creates an instance using the no-args constructor and stores it somewhere. Maybe Lombok could store it in a private static final field of the processed class.

I've been always claiming that omitDefault with JSON is more useful than omitNulls or omitEmpty or any other such option, since its is the only omission leading to the right result on the receiving end. Not sure if this is the most useful option for toString, too.