From 3c47eb1299467f052f25581430d20bc3b2b83f4d Mon Sep 17 00:00:00 2001 From: Reinier Zwitserloot Date: Thu, 18 Nov 2010 12:45:02 +0100 Subject: Added documentation for val and @Getter(lazy=true) and updated docs for Log and EqualsAndHashCode to reflect new lombok 0.10 features. --- website/features/EqualsAndHashCode.html | 8 +++- website/features/GetterLazy.html | 65 +++++++++++++++++++++++++++++++++ website/features/GetterSetter.html | 9 +++-- website/features/Log.html | 9 ++++- website/features/ToString.html | 2 +- website/features/index.html | 4 ++ website/features/val.html | 65 +++++++++++++++++++++++++++++++++ 7 files changed, 155 insertions(+), 7 deletions(-) create mode 100644 website/features/GetterLazy.html create mode 100644 website/features/val.html (limited to 'website') diff --git a/website/features/EqualsAndHashCode.html b/website/features/EqualsAndHashCode.html index c5128d10..dbe45218 100644 --- a/website/features/EqualsAndHashCode.html +++ b/website/features/EqualsAndHashCode.html @@ -28,10 +28,16 @@

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.

diff --git a/website/features/GetterLazy.html b/website/features/GetterLazy.html new file mode 100644 index 00000000..a91e782c --- /dev/null +++ b/website/features/GetterLazy.html @@ -0,0 +1,65 @@ + + + + + + + + @Getter(lazy=true) +
+
+
+ +

@Getter and @Setter

+ +
+

Overview

+

+ 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. +

+
+
+
+

With Lombok

+
@HTML_PRE@
+
+
+
+

Vanilla Java

+
@HTML_POST@
+
+
+
+
+

Small print

+

+ 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. +

+
+
+ +
+
+
+ + + diff --git a/website/features/GetterSetter.html b/website/features/GetterSetter.html index ea1af150..fd4ed17d 100644 --- a/website/features/GetterSetter.html +++ b/website/features/GetterSetter.html @@ -60,15 +60,18 @@

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.

diff --git a/website/features/Log.html b/website/features/Log.html index 6912b6ed..c5d7771c 100644 --- a/website/features/Log.html +++ b/website/features/Log.html @@ -15,7 +15,7 @@

Overview

- 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 @@

Small print

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.

diff --git a/website/features/ToString.html b/website/features/ToString.html index 23041f48..e350c265 100644 --- a/website/features/ToString.html +++ b/website/features/ToString.html @@ -66,7 +66,7 @@
diff --git a/website/features/index.html b/website/features/index.html index d216ddb4..edc173fb 100644 --- a/website/features/index.html +++ b/website/features/index.html @@ -15,6 +15,8 @@
@Getter / @Setter
Never write public int getFoo() {return foo;} again.
+
@Getter(lazy=true)
+
Laziness is a virtue!
@ToString
No need to start a debugger to see your fields: Just let lombok generate a toString for you!
@EqualsAndHashCode
@@ -32,6 +34,8 @@
To boldly throw checked exceptions where no one has thrown them before!
@Log
Captain's Log, stardate 24435.7: "What was that line again?"
+
val
+
Finally! hassle-free final local variables.
diff --git a/website/features/val.html b/website/features/val.html new file mode 100644 index 00000000..a3ce58e0 --- /dev/null +++ b/website/features/val.html @@ -0,0 +1,65 @@ + + + + + + + + @Data +
+
+
+ +

val

+ +
+

Overview

+

+ 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. +

+
+
+
+

With Lombok

+
@HTML_PRE@
+
+
+
+

Vanilla Java

+
@HTML_POST@
+
+
+
+
+

Small print

+

+ 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. +

+
+
+ +
+
+
+ + + -- cgit