The great rename: the old ‘website’ is now ‘website-old’, and ‘website2’ is now ‘website’.

29 files changed, 1763 insertions, 0 deletions

diff --git a/website/templates/features/Builder.html b/website/templates/features/Builder.html
new file mode 100644
index 00000000..a6b8d18f
--- /dev/null
+++ b/website/templates/features/Builder.html
@@ -0,0 +1,163 @@
+<#import "_features.html" as f>
+
+<@f.scaffold title="@Builder" logline="... and Bob's your uncle: No-hassle fancy-pants APIs for object creation!">
+	<@f.history>
+		<p>
+			<code>@Builder</code> was introduced as experimental feature in lombok v0.12.0.
+		</p><p>
+			<code>@Builder</code> gained <code>@Singular</code> support and was promoted to the main <code>lombok</code> package since lombok v1.16.0.
+		</p><p>
+			<code>@Builder</code> with <code>@Singular</code> adds a clear method since lombok v1.16.8.
+		</p><p>
+			<code>@Builder.Default</code> functionality was added in lombok v1.16.16.
+		</p>
+	</@f.history>
+	
+	<@f.overview>
+		<p>
+			The <code>@Builder</code> annotation produces complex builder APIs for your classes.
+		</p><p>
+			<code>@Builder</code> lets you automatically produce the code required to have your class be instantiable with code such as:<br />
+			<code>Person.builder().name("Adam Savage").city("San Francisco").job("Mythbusters").job("Unchained Reaction").build();</code>
+		</p><p>
+			<code>@Builder</code> can be placed on a class, or on a constructor, or on a method. While the "on a class" and "on a constructor" mode are the most common use-case, <code>@Builder</code> is most easily explained with the "method" use-case.
+		</p><p>
+			A method annotated with <code>@Builder</code> (from now on called the <em>target</em>) causes the following 7 things to be generated:
+			<ul>
+				<li>
+					An inner static class named <code><em>Foo</em>Builder</code>, with the same type arguments as the static method (called the <em>builder</em>).
+				</li><li>
+					In the <em>builder</em>: One private non-static non-final field for each parameter of the <em>target</em>.
+				</li><li>
+					In the <em>builder</em>: A package private no-args empty constructor.
+				</li><li>
+					In the <em>builder</em>: A 'setter'-like method for each parameter of the <em>target</em>: It has the same type as that parameter and the same name. It returns the builder itself, so that the setter calls can be chained, as in the above example.
+				</li><li>
+					In the <em>builder</em>: A <code>build()</code> method which calls the method, passing in each field. It returns the same type that the <em>target</em> returns.
+				</li><li>
+					In the <em>builder</em>: A sensible <code>toString()</code> implementation.
+				</li><li>
+					In the class containing the <em>target</em>: A <code>builder()</code> method, which creates a new instance of the <em>builder</em>.
+				</li>
+			</ul>
+			Each listed generated element will be silently skipped if that element already exists (disregarding parameter counts and looking only at names). This includes the <em>builder</em> itself: If that class already exists, lombok will simply start injecting fields and methods inside this already existing class, unless of course the fields / methods to be injected already exist. You may not put any other method (or constructor) generating lombok annotation on a builder class though; for example, you can not put <code>@EqualsAndHashCode</code> on the builder class.
+		</p><p>
+			<code>@Builder</code> can generate so-called 'singular' methods for collection parameters/fields. These take 1 element instead of an entire list, and add the element to the list. For example: <code>Person.builder().job("Mythbusters").job("Unchained Reaction").build();</code> would result in the <code>List&lt;String&gt; jobs</code> field to have 2 strings in it. To get this behaviour, the field/parameter needs to be annotated with <code>@Singular</code>. The feature has <a href="#singular">its own documentation</a>.
+		</p><p>
+			Now that the "method" mode is clear, putting a <code>@Builder</code> annotation on a constructor functions similarly; effectively, constructors are just static methods that have a special syntax to invoke them: Their 'return type' is the class they construct, and their type parameters are the same as the type parameters of the class itself.
+		</p><p>
+			Finally, applying <code>@Builder</code> to a class is as if you added <code>@AllArgsConstructor(access = AccessLevel.PACKAGE)</code> to the class and applied the <code>@Builder</code> annotation to this all-args-constructor. This only works if you haven't written any explicit constructors yourself. If you do have an explicit constructor, put the <code>@Builder</code> annotation on the constructor instead of on the class.
+		</p><p>
+			If using <code>@Builder</code> to generate builders to produce instances of your own class (this is always the case unless adding <code>@Builder</code> to a method that doesn't return your own type), you can use <code>@Builder(toBuilder = true)</code> to also generate an instance method in your class called <code>toBuilder()</code>; it creates a new builder that starts out with all the values of this instance. You can put the <code>@Builder.ObtainVia</code> annotation on the parameters (in case of a constructor or method) or fields (in case of <code>@Builder</code> on a type) to indicate alternative means by which the value for that field/parameter is obtained from this instance. For example, you can specify a method to be invoked: <code>@Builder.ObtainVia(method = "calculateFoo")</code>.
+		</p><p>
+			The name of the builder class is <code><em>Foobar</em>Builder</code>, where <em>Foobar</em> is the simplified, title-cased form of the return type of the <em>target</em> - that is, the name of your type for <code>@Builder</code> on constructors and types, and the name of the return type for <code>@Builder</code> on methods. For example, if <code>@Builder</code> is applied to a class named <code>com.yoyodyne.FancyList&lt;T&gt;</code>, then the builder name will be <code>FancyListBuilder&lt;T&gt;</code>. If <code>@Builder</code> is applied to a method that returns <code>void</code>, the builder will be named <code>VoidBuilder</code>.
+		</p><p>
+			The configurable aspects of builder are:
+			<ul>
+				<li>
+					The <em>builder's class name</em> (default: return type + 'Builder')
+				</li><li>
+					The <em>build()</em> method's name (default: <code>"build"</code>)
+				</li><li>
+					The <em>builder()</em> method's name (default: <code>"builder"</code>)
+				</li><li>
+					If you want <code>toBuilder()</code> (default: no)
+				</li>
+			</ul>
+			Example usage where all options are changed from their defaults:<br />
+			<code>@Builder(builderClassName = "HelloWorldBuilder", buildMethodName = "execute", builderMethodName = "helloWorld", toBuilder = true)</code><br />
+		</p>
+	</@f.overview>
+	
+	<@f.featureSection>
+		<h3 id="builderdefault"><a name="builderdefault">@Builder.Default</a></h3>
+		
+		<p>
+			If a certain field/parameter is never set during a build session, then it always gets 0 / <code>null</code> / false. If you've put <code>@Builder</code> on a class (and not a method or constructor) you can instead specify the default directly on the field, and annotate the field with <code>@Builder.Default</code>:<br />
+			<code>@Builder.Default private final long created = System.currentTimeMillis();</code>	</@f.featureSection>
+		</p>
+	</@f.featureSection>
+	
+	<@f.featureSection>
+		<h3 id="singular"><a name="singular">@Singular</a></h3>
+		
+		<p>
+			By annotating one of the parameters (if annotating a method or constructor with <code>@Builder</code>) or fields (if annotating a class with <code>@Builder</code>) with the <code>@Singular</code> annotation, lombok will treat that builder node as a collection, and it generates 2 'adder' methods instead of a 'setter' method. One which adds a single element to the collection, and one which adds all elements of another collection to the collection. No setter to just set the collection (replacing whatever was already added) will be generated. A 'clear' method is also generated. These 'singular' builders are very complicated in order to guarantee the following properties:
+			<ul>
+				<li>
+					When invoking <code>build()</code>, the produced collection will be immutable.
+				</li><li>
+					Calling one of the 'adder' methods, or the 'clear' method, after invoking <code>build()</code> does not modify any already generated objects, and, if <code>build()</code> is later called again, another collection with all the elements added since the creation of the builder is generated.
+				</li><li>
+					The produced collection will be compacted to the smallest feasible format while remaining efficient.
+				</li>
+			</ul>
+		</p><p>
+			<code>@Singular</code> can only be applied to collection types known to lombok. Currently, the supported types are:
+			<ul>
+				<li>
+					<a href="https://docs.oracle.com/javase/8/docs/api/java/util/package-summary.html"><code>java.util</code></a>:
+					<ul>
+						<li>
+							<code>Iterable</code>, <code>Collection</code>, and <code>List</code> (backed by a compacted unmodifiable <code>ArrayList</code> in the general case).
+						</li><li>
+							<code>Set</code>, <code>SortedSet</code>, and <code>NavigableSet</code> (backed by a smartly sized unmodifiable <code>HashSet</code> or <code>TreeSet</code> in the general case).
+						</li><li>
+							<code>Map</code>, <code>SortedMap</code>, and <code>NavigableMap</code> (backed by a smartly sized unmodifiable <code>HashMap</code> or <code>TreeMap</code> in the general case).
+						</li>
+					</ul>
+				</li><li>
+					<a href="https://github.com/google/guava">Guava</a>'s <code>com.google.common.collect</code>:
+					<ul>
+						<li>
+							<code>ImmutableCollection</code> and <code>ImmutableList</code> (backed by the builder feature of <code>ImmutableList</code>).
+						</li><li>
+							<code>ImmutableSet</code> and <code>ImmutableSortedSet</code> (backed by the builder feature of those types).
+						</li><li>
+							<code>ImmutableMap</code>, <code>ImmutableBiMap</code>, and <code>ImmutableSortedMap</code> (backed by the builder feature of those types).
+						</li><li>
+							<code>ImmutableTable</code> (backed by the builder feature of <code>ImmutableTable</code>).
+						</li>
+					</ul>
+				</li>
+			</ul>
+		</p><p>
+			If your identifiers are written in common english, lombok assumes that the name of any collection with <code>@Singular</code> on it is an english plural and will attempt to automatically singularize that name. If this is possible, the add-one method will use this name. For example, if your collection is called <code>statuses</code>, then the add-one method will automatically be called <code>status</code>. You can also specify the singular form of your identifier explictly by passing the singular form as argument to the annotation like so: <code>@Singular("axis") List&lt;Line&gt; axes;</code>.<br />
+			If lombok cannot singularize your identifier, or it is ambiguous, lombok will generate an error and force you to explicitly specify the singular name.
+		</p><p>
+				The snippet below does not show what lombok generates for a <code>@Singular</code> field/parameter because it is rather complicated. You can view a snippet <a href="builderSingular">here</a>.
+		</p>
+	</@f.featureSection>
+
+	<@f.snippets name="Builder" />
+
+	<@f.confKeys>
+		<dt>
+			<code>lombok.builder.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
+		</dt><dd>
+			Lombok will flag any usage of <code>@Builder</code> as a warning or error if configured.
+		</dd><dt>
+			<code>lombok.singular.useGuava</code> = [<code>true</code> | <code>false</code>] (default: false)
+		</dt><dd>
+			If <code>true</code>, lombok will use guava's <code>ImmutableXxx</code> builders and types to implement <code>java.util</code> collection interfaces, instead of creating implementations based on <code>Collections.unmodifiableXxx</code>. You must ensure that guava is actually available on the classpath and buildpath if you use this setting. Guava is used automatically if your field/parameter has one of the guava <code>ImmutableXxx</code> types.
+		</dd><dt>
+			<code>lombok.singular.auto</code> = [<code>true</code> | <code>false</code>] (default: true)
+		</dt><dd>
+			If <code>true</code> (which is the default), lombok automatically tries to singularize your identifier name by assuming that it is a common english plural. If <code>false</code>, you must always explicitly specify the singular name, and lombok will generate an error if you don't (useful if you write your code in a language other than english).
+		</dd>
+	</@f.confKeys>
+
+	<@f.smallPrint>
+		<p>
+			@Singular support for <code>java.util.NavigableMap/Set</code> only works if you are compiling with JDK1.8 or higher.
+		</p><p>
+			You cannot manually provide some or all parts of a <code>@Singular</code> node; the code lombok generates is too complex for this. If you want to manually control (part of) the builder code associated with some field or parameter, don't use <code>@Singular</code> and add everything you need manually.
+		</p><p>
+			The sorted collections (java.util: <code>SortedSet</code>, <code>NavigableSet</code>, <code>SortedMap</code>, <code>NavigableMap</code> and guava: <code>ImmutableSortedSet</code>, <code>ImmutableSortedMap</code>) require that the type argument of the collection has natural order (implements <code>java.util.Comparable</code>). There is no way to pass an explicit <code>Comparator</code> to use in the builder.
+		</p><p>
+			An <code>ArrayList</code> is used to store added elements as call methods of a <code>@Singular</code> marked field, if the target collection is from the <code>java.util</code> package, <em>even if the collection is a set or map</em>. Because lombok ensures that generated collections are compacted, a new backing instance of a set or map must be constructed anyway, and storing the data as an <code>ArrayList</code> during the build process is more efficient that storing it as a map or set. This behaviour is not externally visible, an implementation detail of the current implementation of the <code>java.util</code> recipes for <code>@Singular @Builder</code>.
+		</p><p>
+			With <code>toBuilder = true</code> applied to methods, any type parameter of the annotated method itself must also show up in the return type.
+		</p>
+	</@f.smallPrint>
+</@f.scaffold>
diff --git a/website/templates/features/BuilderSingular.html b/website/templates/features/BuilderSingular.html
new file mode 100644
index 00000000..10253365
--- /dev/null
+++ b/website/templates/features/BuilderSingular.html
@@ -0,0 +1,5 @@
+<#import "_features.html" as f>
+
+<@f.scaffold title="@Builder @Singular" logline="... and Bob's your uncle: No-hassle fancy-pants APIs for object creation!">
+	<@f.snippets name="Singular-snippet" />
+</@f.scaffold>
diff --git a/website/templates/features/Cleanup.html b/website/templates/features/Cleanup.html
new file mode 100644
index 00000000..e868c40d
--- /dev/null
+++ b/website/templates/features/Cleanup.html
@@ -0,0 +1,35 @@
+<#import "_features.html" as f>
+
+<@f.scaffold title="@Cleanup" logline="Automatic resource management: Call your <code>close()</code> methods safely with no hassle.">
+	<@f.overview>
+		<p>
+			You can use <code>@Cleanup</code> to ensure a given resource is automatically cleaned up before the code execution path exits your current scope. You do this by annotating any local variable declaration with the <code>@Cleanup</code> annotation like so:<br />
+			<code>@Cleanup InputStream in = new FileInputStream("some/file");</code><br />
+			As a result, at the end of the scope you're in, <code>in.close()</code> is called. This call is guaranteed to run by way of a try/finally construct. Look at the example below to see how this works.
+		</p><p>
+			If the type of object you'd like to cleanup does not have a <code>close()</code> method, but some other no-argument method, you can specify the name of this method like so:<br />
+			<code>@Cleanup("dispose") org.eclipse.swt.widgets.CoolBar bar = new CoolBar(parent, 0);</code><br />
+			By default, the cleanup method is presumed to be <code>close()</code>. A cleanup method that takes 1 or more arguments cannot be called via <code>@Cleanup</code>.
+		</p>
+	</@f.overview>
+
+	<@f.snippets name="Cleanup" />
+
+	<@f.confKeys>
+		<dt>
+			<code>lombok.cleanup.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
+		</dt></dd>
+			Lombok will flag any usage of <code>@Cleanup</code> as a warning or error if configured.
+		</dd>
+	</@f.confKeys>
+
+	<@f.smallPrint>
+		<p>
+			In the finally block, the cleanup method is only called if the given resource is not <code>null</code>. However, if you use <code>delombok</code> on the code, a call to <code>lombok.Lombok.preventNullAnalysis(Object o)</code> is inserted to prevent warnings if static code analysis could determine that a null-check would not be needed. Compilation with <code>lombok.jar</code> on the classpath removes that method call, so there is no runtime dependency.
+		</p><p>
+			If your code throws an exception, and the cleanup method call that is then triggered also throws an exception, then the original exception is hidden by the exception thrown by the cleanup call. You should <em>not</em> rely on this 'feature'. Preferably, lombok would like to generate code so that, if the main body has thrown an exception, any exception thrown by the close call is silently swallowed (but if the main body exited in any other way, exceptions by the close call will not be swallowed). The authors of lombok do not currently know of a feasible way to implement this scheme, but if java updates allow it, or we find a way, we'll fix it.
+		</p><p>
+			You do still need to handle any exception that the cleanup method can generate!
+		</p>
+	</@f.smallPrint>
+</@f.scaffold>
diff --git a/website/templates/features/Data.html b/website/templates/features/Data.html
new file mode 100644
index 00000000..59370cc8
--- /dev/null
+++ b/website/templates/features/Data.html
@@ -0,0 +1,41 @@
+<#import "_features.html" as f>
+
+<@f.scaffold title="@Data"
+	logline="All together now: A shortcut for <code>@ToString</code>, <code>@EqualsAndHashCode</code>, <code>@Getter</code> on all fields, <code>@Setter</code> on all non-final fields, and <code>@RequiredArgsConstructor</code>!">
+
+	<@f.overview>
+		<p>
+			<code>@Data</code> is a convenient shortcut annotation that bundles the features of <a href="/features/ToString"><code>@ToString</code></a>, <a href="/features/EqualsAndHashCode"><code>@EqualsAndHashCode</code></a>, <a href="/features/GetterSetter"><code>@Getter</code> / <code>@Setter</code></a> and <a href="/features/constructor"><code>@RequiredArgsConstructor</code></a> together: In other words, <code>@Data</code> generates <em>all</em> the boilerplate that is normally associated with simple POJOs (Plain Old Java Objects) and beans: getters for all fields, setters for all non-final fields, and appropriate <code>toString</code>, <code>equals</code> and <code>hashCode</code> implementations that involve the fields of the class, and a constructor that initializes all final fields, as well as all non-final fields with no initializer that have been marked with <code>@NonNull</code>, in order to ensure the field is never null.
+		</p><p>
+			<code>@Data</code> is like having implicit <code>@Getter</code>, <code>@Setter</code>, <code>@ToString</code>, <code>@EqualsAndHashCode</code> and <code>@RequiredArgsConstructor</code> annotations on the class (except that no constructor will be generated if any explicitly written constructors already exist). However, the parameters of these annotations (such as <code>callSuper</code>, <code>includeFieldNames</code> and <code>exclude</code>) cannot be set with <code>@Data</code>. If you need to set non-default values for any of these parameters, just add those annotations explicitly; <code>@Data</code> is smart enough to defer to those annotations.
+		</p><p>
+			All generated getters and setters will be <code>public</code>. To override the access level, annotate the field or class with an explicit <code>@Setter</code> and/or <code>@Getter</code> annotation. You can also use this annotation (by combining it with <code>AccessLevel.NONE</code>) to suppress generating a getter and/or setter altogether.
+		</p><p>
+			All fields marked as <code>transient</code> will not be considered for <code>hashCode</code> and <code>equals</code>. All static fields will be skipped entirely (not considered for any of the generated methods, and no setter/getter will be made for them).
+		</p><p>
+			If the class already contains a method with the same name and parameter count as any method that would normally be generated, that method is not generated, and no warning or error is emitted. For example, if you already have a method with signature <code>equals(AnyType param)</code>, no <code>equals</code> method will be generated, even though technically it might be an entirely different method due to having different parameter types. The same rule applies to the constructor (any explicit constructor will prevent <code>@Data</code> from generating one), as well as <code>toString</code>, <code>equals</code>, and all getters and setters. You can mark any constructor or method with <code>@lombok.experimental.Tolerate</code> to hide them from lombok.
+		</p><p>
+			<code>@Data</code> can handle generics parameters for fields just fine. In order to reduce the boilerplate when constructing objects for classes with generics, you can use the <code>staticConstructor</code> parameter to generate a private constructor, as well as a static method that returns a new instance. This way, javac will infer the variable name. Thus, by declaring like so: <code>@Data(staticConstructor="of") class Foo&lt;T&gt; { private T x;}</code> you can create new instances of <code>Foo</code> by writing: <code>Foo.of(5);</code> instead of having to write: <code>new Foo&lt;Integer&gt;(5);</code>.
+		</p>
+	</@f.overview>
+
+	<@f.snippets name="Data" />
+
+	<@f.confKeys>
+		<dt>
+			<code>lombok.data.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
+		</dt><dd>
+			Lombok will flag any usage of <code>@Data</code> as a warning or error if configured.
+		</dd>
+	</@f.confKeys>
+
+	<@f.smallPrint>
+		<p>
+			See the small print of <a href="/features/ToString"><code>@ToString</code></a>, <a href="/features/EqualsAndHashCode"><code>@EqualsAndHashCode</code></a>, <a href="/features/GetterSetter"><code>@Getter / @Setter</code></a> and <a href="/features/constructor">@RequiredArgsConstructor</a>.
+		</p><p>
+			Any annotations named <code>@NonNull</code> (case insensitive) on a field are interpreted as: This field must not ever hold <em>null</em>. Therefore, these annotations result in an explicit null check in the generated constructor for the provided field. Also, these annotations (as well as any annotation named <code>@Nullable</code>) are copied to the constructor parameter, in both the true constructor and any static constructor. The same principle applies to generated getters and setters (see the documentation for <a href="/features/GetterSetter">@Getter / @Setter</a>)
+		</p><p>
+			By default, any variables that start with a $ symbol are excluded automatically. You can include them by specifying an explicit annotation (<code>@Getter</code> or <code>@ToString</code>, for example) and using the 'of' parameter.
+		</p>
+	</@f.smallPrint>
+</@f.scaffold>
diff --git a/website/templates/features/EqualsAndHashCode.html b/website/templates/features/EqualsAndHashCode.html
new file mode 100644
index 00000000..3c11367f
--- /dev/null
+++ b/website/templates/features/EqualsAndHashCode.html
@@ -0,0 +1,56 @@
+<#import "_features.html" as f>
+
+<@f.scaffold title="@EqualsAndHashCode" logline="Equality made easy: Generates <code>hashCode</code> and <code>equals</code> implementations from the fields of your object.">
+	<@f.overview>
+		<p>
+			Any class definition may be annotated with <code>@EqualsAndHashCode</code> to let lombok generate implementations of the <code>equals(Object other)</code> and <code>hashCode()</code> methods. By default, it'll use all non-static, non-transient fields, but you can exclude more fields by naming them in the optional <code>exclude</code> parameter to the annotation. Alternatively, you can specify exactly which fields you wish to be used by naming them in the <code>of</code> parameter.
+		</p><p>
+			If applying <code>@EqualsAndHashCode</code> to a class that extends another, this feature gets a bit trickier. Normally, auto-generating an <code>equals</code> and <code>hashCode</code> method for such classes is a bad idea, as the superclass also defines fields, which also need equals/hashCode code but this code will not be generated. By setting <code>callSuper</code> to <em>true</em>, you can include the <code>equals</code> and <code>hashCode</code> methods of your superclass in the generated methods. For <code>hashCode</code>, the result of <code>super.hashCode()</code> is included in the hash algorithm, and for<code>equals</code>, the generated method will return false if the super implementation thinks it is not equal to the passed in object. Be aware that not all <code>equals</code> implementations handle this situation properly. However, lombok-generated <code>equals</code> implementations <strong>do</strong> handle this situation properly, so you can safely call your superclass equals if it, too, has a lombok-generated <code>equals</code> method. If you have an explicit superclass you are forced to supply some value for <code>callSuper</code> to acknowledge that you've considered it; failure to do so results in a warning.
+		</p><p>
+			Setting <code>callSuper</code> to <em>true</em> when you don't extend anything (you extend <code>java.lang.Object</code>) is a compile-time error, because it would turn the generated <code>equals()</code> and <code>hashCode()</code> implementations into having the same behaviour as simply inheriting these methods from <code>java.lang.Object</code>: only the same object will be equal to each other and will have the same hashCode. Not setting <code>callSuper</code> to <em>true</em> 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 <code>callSuper</code> chaining facility. You can also use the <code>lombok.equalsAndHashCode.callSuper</code> config key.
+		</p><p>
+			<em>NEW in Lombok 0.10: </em>Unless your class is <code>final</code> and extends <code>java.lang.Object</code>, lombok generates a <code>canEqual</code> 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: <a href="https://www.artima.com/lejava/articles/equality.html">How to Write an Equality Method in Java</a>. 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 <code>canEqual</code> if you change <code>equals</code> and <code>hashCode</code>.
+		</p><p>
+			<em>NEW in Lombok 1.14.0: </em>To put annotations on the <code>other</code> parameter of the <code>equals</code> (and, if relevant, <code>canEqual</code>) method, you can use <code>onParam=@__({@AnnotationsHere})</code>. Be careful though! This is an experimental feature. For more details see the documentation on the <a ng-click="toFeature('on-x')">onX</a> feature.
+		</p>
+	</@f.overview>
+
+	<@f.snippets name="EqualsAndHashCode" />
+
+	<@f.confKeys>
+		<dt>
+			<code>lombok.equalsAndHashCode.doNotUseGetters</code> = [<code>true</code> | <code>false</code>] (default: false)
+		</dt><dd>
+			If set to <code>true</code>, lombok will access fields directly instead of using getters (if available) when generating <code>equals</code> and <code>hashCode</code> methods. The annotation parameter '<code>doNotUseGetters</code>', if explicitly specified, takes precedence over this setting.
+		</dd><dt>
+			<code>lombok.equalsAndHashCode.callSuper</code> = [<code>call</code> | <code>skip</code> | <code>warn</code>] (default: warn)
+		</dt><dd>
+			If set to <code>call</code>, lombok will generate calls to the superclass implementation of <code>hashCode</code> and <code>equals</code> if your class extends something. If set to <code>skip</code> no such calls are generated. The default behaviour is like <code>skip</code>, with an additional warning.
+		</dd><dt>
+			<code>lombok.equalsAndHashCode.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
+		</dt><dd>
+			Lombok will flag any usage of <code>@EqualsAndHashCode</code> as a warning or error if configured.
+		</dd>
+	</@f.confKeys>
+
+	<@f.smallPrint>
+		<p>
+			Arrays are 'deep' compared/hashCoded, which means that arrays that contain themselves will result in <code>StackOverflowError</code>s. However, this behaviour is no different from e.g. <code>ArrayList</code>.
+		</p><p>
+			You may safely presume that the hashCode implementation used will not change between versions of lombok, however this guarantee is not set in stone; if there's a significant performance improvement to be gained from using an alternate hash algorithm, that will be substituted in a future version.
+		</p><p>
+			For the purposes of equality, 2 <code>NaN</code> (not a number) values for floats and doubles are considered equal, eventhough 'NaN == NaN' would return false. This is analogous to <code>java.lang.Double</code>'s equals method, and is in fact required to ensure that comparing an object to an exact copy of itself returns <code>true</code> for equality.
+		</p><p>
+			If there is <em>any</em> method named either <code>hashCode</code> or <code>equals</code>, regardless of return type, no methods will be generated, and a warning is emitted instead. These 2 methods need to be in sync with each other, which lombok cannot guarantee unless it generates all the methods, hence you always get a warning if one <em>or</em> both of the methods already exist. You can mark any method with <code>@lombok.experimental.Tolerate</code> to hide them from lombok.
+		</p><p>
+			Attempting to exclude fields that don't exist or would have been excluded anyway (because they are static or transient) results in warnings on the named fields. You therefore don't have to worry about typos.
+		</p><p>
+			Having both <code>exclude</code> and <code>of</code> generates a warning; the <code>exclude</code> parameter will be ignored in that case.
+		</p><p>
+			By default, any variables that start with a $ symbol are excluded automatically. You can onlyinclude them by using the 'of' parameter.
+		</p><p>
+			If a getter exists for a field to be included, it is called instead of using a direct field reference. This behaviour can be suppressed:<br />
+			<code>@EqualsAndHashCode(doNotUseGetters = true)</code>
+		</p>
+	</@f.smallPrint>
+</@f.scaffold>
diff --git a/website/templates/features/GetterLazy.html b/website/templates/features/GetterLazy.html
new file mode 100644
index 00000000..b1f374a8
--- /dev/null
+++ b/website/templates/features/GetterLazy.html
@@ -0,0 +1,31 @@
+<#import "_features.html" as f>
+
+<@f.scaffold title="@Getter(lazy=true)" logline="Laziness is a virtue!">
+	<@f.history>
+		<code>@Getter(lazy=true)</code> was introduced in Lombok v0.10.
+	</@f.history>
+	
+	<@f.overview>
+		<p>