Feature suggestion: @DeepClone annotation

[Tumi]

Hi,

I'm new to Lombok but I already love it.... congrats and thank you all
who work on it! :-)

Maybe this has been sugested/discussed before, sorry if it's the case:

It would be very interesting (and coherent with "the Lombok word")
having a @Clone or @DeppepClone annotation, which would add the
"implements Cloneable" clause to the class definiton and also the
implementetin of the clone method with the deep clone of its non-
transient fields (only those implementing Cloneable). The annotation
should have a callSuper attribute, coherent with the rest of the
framework.

Imho, the @Data convenient annotation should include this feature,
also.

Easy to explain, surely hard to implement?

P.S: By the way, do you plan to integrate a callSuper attribute in
@Data? Here is my +1 :-) I have read in the group that it was
planned for version 0.10.0, but I don't see it in the realease notes.


Thank you and regards,

[Reinier Zwitserloot]

I'm up for all four suggestions:

* Add a @Clone annotation. @Cloneable would be better but that already exists.

* Give @Clone a callSuper property.

* Make @Clone be part of what @Data does.

* Give @Data a callSuper property which is simply forwarded to @ToString, @EqAHC, and @Clone.

We'll discuss it next lombok hack night (usually monday evenings).

[Tumi]

Great :)

I also suggest giving an includeTransient attribute to @Clone. And
decide if transient fields should be cloned by default (as
Object.clone does) or if not (as the "cloning" Serialization
behabiour, and also equivalent to the @EqualsAndHashCode exclusion).

By the way, is there any way to include transient fields in
EqualsAndHashCode?

Regards.

[eric.giese]

> Make @Clone be part of what @Data does.

How to handle final fields? Since the native clone can't call them,
and you can't really trust into having the right constructor at hand,
this could cause problems. If possible, @Clone should emit an error if
the class is not cloneable, and @Data should not include this
annotation in that case. Then it would be a great feature for mutable
classes.

Concerning transient fields:
- Clone should "clone" them, as the jdk does.
-They should not be included in lomboks equals/hashcode. transient is
for fields which either hold internal state or pre-computed "lazy"
values like hashcodes or toStrings. The first one (state) is not safe
for equals/hashcode while the later is not relevant, as its the result
of the other-fields.