From 3c47eb1299467f052f25581430d20bc3b2b83f4d Mon Sep 17 00:00:00 2001
From: Reinier Zwitserloot
Setting callSuper
to true when you don't extend anything (you extend java.lang.Object
) is a compile-time error, because it would turn
the generated equals()
and hashCode()
implementations into having the same behaviour as simply inheriting these methods from java.lang.Object
:
- only the same object will be equal to each other and will have the same hashCode. Obviously, inheriting java.lang.Object
is the right strategy if you want this behaviour.
+ only the same object will be equal to each other and will have the same hashCode.
Not setting callSuper
to true when you extend another class generates a warning, because unless the superclass has no (equality-important) fields, lombok
cannot generate an implementation for you that takes into account the fields declared by your superclasses. You'll need to write your own implementations, or rely on the
callSuper
chaining facility.
+
+ NEW in Lombok 0.10: Unless your class is final
and extends java.lang.Object
, lombok generates a canEqual
method
+ which means JPA proxies can still be equal to their base class, but subclasses that add new state don't break the equals contract. The complicated reasons for
+ why such a method is necessary are explained in this paper: (TODO: Find link to Venners/Spoon/Odersky). If all classes in a hierarchy are a mix of scala case classes
+ and classes with lombok-generated equals methods, all equality will 'just work'. If you need to write your own equals methods, you should always override canEqual
+ if you change equals
and hashCode
.
+ NEW IN Lombok 0.10: You can let lombok generate a getter which will calculate a value once, the first time this getter is called, and cache it from then on. This can be useful
+ if calculating the value takes a lot of CPU, or the value takes a lot of memory. To use this feature, create a private final
variable,
+ initialize it with the expression that's expensive to run, and annotate your field with @Getter(lazy=true)
. The field will be hidden from the
+ rest of your code, and the expression will be evaluated no more than once, when the getter is first called. There are no magic marker values (i.e. even
+ if the result of your expensive calculation is null
, the result is cached) and your expensive calculation need not be thread-safe, as lombok
+ takes care of locking.
+
+ Lombok actually creates a few fields all prefixed with $lombok$
to cache the value. You should not rely on the exact type, name, and structure
+ of these fields as future implementations may change them. To access the lazily initialized value, always use the generated getter.
+
+ Other Lombok annotations such as @ToString
always call the getter even if you use doNotUseGetters=true
.
+
Any annotations named @NonNull
(case insensitive) on the field are interpreted as: This field must not ever hold
null. Therefore, these annotations result in an explicit null check in the generated setter. Also, these
- annotations (as well as any annotation named @Nullable
or @CheckForNull
) are copied to setter parameter and getter method
+ annotations (as well as any annotation named @Nullable
or @CheckForNull
) are copied to setter parameter and getter method.
+
+ You can annotate a class with a @Getter
or @Setter
annotation. Doing so is equivalent to annotating all non-static fields
+ in that class with that annotation. @Getter
/@Setter
annotations on fields take precedence over the ones on classes.
Using the AccessLevel.NONE
access level simply generates nothing. It's useful only in combination with
- @Data
.
+ @Data
or a class-wide @Getter
or @Setter
.
- You can annotate any field with @Log
to let lombok generate a logger field automatically.
+ NEW in lombok 0.10: You can annotate any field with @Log
to let lombok generate a logger field automatically.
The logger is named log
and field's type depends on which logger you have selected.
There are four @Log
choices available:
@@ -50,11 +50,16 @@
If a field called log
already exists, a warning will be emitted and no code will be generated.
+
+ A future feature of lombok's @Log
is to find calls to the logger field and, if the chosen logging framework supports
+ it and the log level can be compile-time determined from the log call, guard it with an if
statement. This way if
+ the log statement ends up being ignored, the potentially expensive calculation of the log string is avoided entirely. This does mean
+ that you should NOT put any side-effects in the expression that you log.
@Getter
/ @Setter
public int getFoo() {return foo;}
again.@Getter(lazy=true)
@ToString
toString
for you!@EqualsAndHashCode
@Log
val
+ NEW in Lombok 0.10: You can use val
as the type of a local variable declaration instead of actually writing the type. When you do this,
+ the type will be inferred from the initializer expression. The local variable will also be made final. This feature works
+ on local variables and on foreach loops only, not on fields. The initializer expression is required.
+
+ WARNING: This feature does not currently work in NetBeans. We're working on fixing that. +
+
+ For compound types, the most common superclass is inferred, not any shared interfaces. For example, bool ? new HashSet() : new ArrayList()
+ is an expression with a compound type: The result is both AbstractCollection
as well as Serializable
. The type inferred will be
+ AbstractCollection
, as that is a class, whereas Serializable
is an interface.
+
+ In ambiguous cases, such as when the initializer expression is null
, java.lang.Object
is inferred.
+