Some annotations are meant for fields, others are meant for the getter
method. Others are for the setter method. Still others are for the
parameter of the setter. Or a mix of any of those 4.
We have no idea way of knowing what mix is needed. Therefore, lombok
does not copy over annotations because it has no idea of knowing where
the annotation should be copied, whether or not it should delete the
original, and how many copies should be made. The only exception to
this rule is various takes on NonNull, Nullable, and CanBeNull,
because we know where those should go (stay on the field, copy to
getter method, copy to setter parameter).
There's also no convenient syntax we can think of that will let you
specify what lombok should do. The best we can come up with is
something like:
@XmlTransient
@Getter(annotations=@MoveAnnotation(name="XmlTransient"))
@Setter(annotations=@MoveAnnotation(name="XmlTransient",
where=Setter.AnnotationLocations.METHOD))
private final FieldType someField;
which is about as long as writing the setters and getters out by hand,
so pointless. We don't want lombok to become some sort of awkward DSL
for writing java code that isn't particularly obvious in the first
place.
An alternative would be:
@Getter(addToMethod="@XmlTransient")
@Setter(addToMethod="@XmlTransient", addToParam="@Whatever")
private final FieldType someField;
which is shorter, but we don't allow you to write java code in string
literals unless there's an extremely compelling reason to do so,
because it breaks lots and lots of tools - refactor tools won't pick
these up when you rename the annotation, syntax highlighting of course
won't work, and trying to use "go to declaration" on anything in a
string literal obviously won't work. You also get fairly surprising
import errors, as eclipse or whatever IDE you are using won't
understand that you need to import these annotations, and will in fact
complain of an unused import if you try, so pragmatically speaking you
have to use fully qualified names there. Does more harm than good.
What's really needed is some sort of central database that contains
the knowledge of what "XmlTransient" is supposed to mean when it shows
up a field that has @Getter and/or @Setter applied to it. However, if
we give control of this db to the programmer, then NOT adding a rule
for @XmlTransient to a db when some other programmer did means the
same piece of code compiles to something completely different on your
machine vs. some other programmer's machine, most likely without any
compiler errors or warnings, which is obviously a very bad thing.
Basically we're not moving on this issue because all the solutions we
can think of have drawbacks that seem worse than simply being forced
to manually write out the setters and getters as the lombok-less
masses have to do, when you need annotations on any aspect of those
methods.