@ToString creates additional unneeded field

The reason for its existence is for legacy behavior of @Immutable which calls through to @ToString. With @Immutable classes created using the named params constructor automatically print out with printNames true whereas ones created with a tuple constructor don't. Current thinking is that we may deprecate this behavior as we have had no feedback indicating that it is absolutely essential for some particular use case and it does add complexity.

The field is marked "synthetic" and that is enough for some tools to ignore it - for XStream you would have to add an XStream annotation to ignore it or write your own convertor. CGLibConverter for example ignores synthetic fields I believe. This would be the workaround.

You mention "causes havoc". What exactly do you observe?

How can I add an XStream annotation to a field generated during compiling? Or do you mean something like private transient boolean $print$names = true would work?

I agree, maybe havoc was the wrong word.

I was hoping XStreamOmitField could be placed on a class with a list of fields to omit but it isn't designed that way at all after checking.

Got interested in how to solve this problem, and documented a technique here as it could be useful to others as well: http://roshandawrani.wordpress.com/2011/09/13/better-serialization-of-groovy-objects-using-xstream/

What should we do about this issue then?

I thought Paul's comment clarified that all Groovy can do is mark its internal fields "synthetic" and then let the libraries utilize that meta-data to ignore them (like CGLibConverter does). And now we have provided a XStream specific workaround as well.

Let's still wait for a little while for Johann to share his views about it.

Yes, with Roshan's published workaround I would recommend closing the issue if Johann agrees. We might as a separate activity want to deprecate the use of '$print$names' but that is a separate issue.

The issue I think about here is that of annotations creating non-static fields. People can say "Groovy is slow" and that's one (largely irrelevant) thing but if they say "Groovy is slow and its memory usage is completely unpredictable and therefore, it cannot scale," that's unacceptable.

In other words, if I didn't know it, I wouldn't expect Groovy to add fields to my classes. The fields it adds today are thankfully static so it's not really an issue but per-instance fields might be.

I'm going to go ahead and close this issue. The internal $print$names field has been removed from Groovy 2.0 in any case. In general, annotations don't add fields (static or otherwise) without careful consideration. It would only be because such a field was required for the functionality of the annotation.

I just looked at the code changes I made for this for 2.0-beta-2 and they didn't seem to be committed - I presume I stuffed up the git command at this end. Re-applying shortly and I'll bump the fix version appropriately.

fixed glitch