Updated just about all of the pages to the template-based redesign.

Added ajaxified loading for feature pages.

27 files changed, 1650 insertions, 0 deletions

diff --git a/website2/templates/features/EqualsAndHashCode.html b/website2/templates/features/EqualsAndHashCode.html
new file mode 100644
index 00000000..91a9cb70
--- /dev/null
+++ b/website2/templates/features/EqualsAndHashCode.html
@@ -0,0 +1,52 @@
+<#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>
+			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.<br/>
+		</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.
+		</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.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/website2/templates/features/GetterLazy.html b/website2/templates/features/GetterLazy.html
new file mode 100644
index 00000000..b1f374a8
--- /dev/null
+++ b/website2/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>
+			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 <code>private final</code> variable, initialize it with the expression that's expensive to run, and annotate your field with <code>@Getter(lazy=true)</code>. 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 <code>null</code>, the result is cached) and your expensive calculation need not be thread-safe, as lombok takes care of locking.
+		</p>
+	</@f.overview>
+
+	<@f.snippets name="GetterLazy" />
+
+	<@f.confKeys>
+		<dt>
+			<code>lombok.getter.lazy.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
+		</dt><dd>
+			Lombok will flag any usage of <code>@Getter(lazy=true)</code> as a warning or error if configured.
+		</dd>
+	</@f.confKeys>
+
+	<@f.smallPrint>
+		<p>
+			You should never refer to the field directly, always use the getter generated by lombok, because the type of the field will be mangled into an <code>AtomicReference</code>. Do not try to directly access this <code>AtomicReference</code>; if it points to itself, the value has been calculated, and it is <code>null</code>. If the reference points to <code>null</code>, then the value has not been calculated. This behaviour may change in future versions. Therefore, <em>always</em> use the generated getter to access your field!
+		</p><p>
+			Other Lombok annotations such as <code>@ToString</code> always call the getter even if you use <code>doNotUseGetters=true</code>.
+		</p>
+	</@f.smallPrint>
+</@f.scaffold>
diff --git a/website2/templates/features/GetterSetter.html b/website2/templates/features/GetterSetter.html
new file mode 100644
index 00000000..7ceaa3ba
--- /dev/null
+++ b/website2/templates/features/GetterSetter.html
@@ -0,0 +1,70 @@
+<#import "_features.html" as f>
+
+<@f.scaffold title="@Getter and @Setter" logline="Never write <code>public int getFoo() {return foo;}</code> again.">
+	<@f.overview>
+		<p>
+			You can annotate any field with <code>@Getter</code> and/or <code>@Setter</code>, to let lombok generate the default getter/setter automatically.<br />
+			A default getter simply returns the field, and is named <code>getFoo</code> if the field is called <code>foo</code> (or <code>isFoo</code> if the field's type is <code>boolean</code>). A default setter is named <code>setFoo</code> if the field is called <code>foo</code>, returns <code>void</code>, and takes 1 parameter of the same type as the field. It simply sets the field to this value.
+		</p><p>
+			The generated getter/setter method will be <code>public</code> unless you explicitly specify an <code>AccessLevel</code>, as shown in the example below. Legal access levels are <code>PUBLIC</code>, <code>PROTECTED</code>, <code>PACKAGE</code>, and <code>PRIVATE</code>.
+		</p><p>
+			You can also put a <code>@Getter</code> and/or <code>@Setter</code> annotation on a class. In that case, it's as if you annotate all the non-static fields in that class with the annotation.
+		</p><p>
+			You can always manually disable getter/setter generation for any field by using the special <code>AccessLevel.NONE</code> access level. This lets you override the behaviour of a <code>@Getter</code>, <code>@Setter</code> or <code>@Data</code> annotation on a class.
+		</p><p>
+			To put annotations on the generated method, you can use <code>onMethod=@__({@AnnotationsHere})</code>; to put annotations on the only parameter of a generated setter 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 href="/features/experimental/onX">onX</a> feature.
+		</p><p>
+			<em>NEW in lombok v1.12.0:</em> javadoc on the field will now be copied to generated getters and setters. Normally, all text is copied, and <code>@return</code> is <em>moved</em> to the getter, whilst <code>@param</code> lines are <em>moved</em> to the setter. Moved means: Deleted from the field's javadoc. It is also possible to define unique text for each getter/setter. To do that, you create a 'section' named <code>GETTER</code> and/or <code>SETTER</code>. A section is a line in your javadoc containing 2 or more dashes, then the text 'GETTER' or 'SETTER', followed by 2 or more dashes, and nothing else on the line. If you use sections, <code>@return</code> and <code>@param</code> stripping for that section is no longer done (move the <code>@return</code> or <code>@param</code> line into the section).
+		</p>
+	</@f.overview>
+
+	<@f.snippets name="GetterSetter" />
+
+	<@f.confKeys>
+		<dt>
+			<code>lombok.accessors.chain</code> = [<code>true</code> | <code>false</code>] (default: false)
+		</dt><dd>
+			If set to <code>true</code>, generated setters will return <code>this</code> (instead of <code>void</code>). An explicitly configured <code>chain</code> parameter of an <a href="/features/experimental/Accessors"><code>@Accessors</code></a> annotation takes precedence over this setting.
+		</dd><dt>
+			<code>lombok.accessors.fluent</code> = [<code>true</code> | <code>false</code>] (default: false)
+		</dt><dd>
+			If set to <code>true</code>, generated getters and setters will not be prefixed with the bean-standard '<code>get</code>, <code>is</code> or <code>set</code>; instead, the methods will use the same name as the field (minus prefixes). An explicitly configured <code>chain</code> parameter of an <a href="/features/experimental/Accessors"><code>@Accessors</code></a> annotation takes precedence over this setting.
+		</dd><dt>
+			<code>lombok.accessors.prefix</code> += <em>a field prefix</em> (default: empty list)
+		</dt><dd>
+			This is a list property; entries can be added with the <code>+=</code> operator. Inherited prefixes from parent config files can be removed with the <code>-=</code> operator. Lombok will strip any matching field prefix from the name of a field in order to determine the name of the getter/setter to generate. For example, if <code>m</code> is one of the prefixes listed in this setting, then a field named <code>mFoobar</code> will result in a getter named <code>getFoobar()</code>, not <code>getMFoobar()</code>. An explicitly configured <code>prefix</code> parameter of an <a href="/features/experimental/Accessors"><code>@Accessors</code></a> annotation takes precedence over this setting.
+		</dd><dt>
+			<code>lombok.getter.noIsPrefix</code> = [<code>true</code> | <code>false</code>] (default: false)
+		</dt><dd>
+			If set to <code>true</code>, getters generated for <code>boolean</code> fields will use the <code>get</code> prefix instead of the default<code>is</code> prefix, and any generated code that calls getters, such as <code>@ToString</code>, will also use <code>get</code> instead of <code>is</code>
+		</dd><dt>
+			<code>lombok.setter.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
+		</dt><dd>
+			Lombok will flag any usage of <code>@Setter</code> as a warning or error if configured.
+		</dd><dt>
+			<code>lombok.getter.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
+		</dt><dd>
+			Lombok will flag any usage of <code>@Getter</code> as a warning or error if configured.
+		</dd>
+	</@f.confKeys>
+
+	<@f.smallPrint>
+		<p>
+			For generating the method names, the first character of the field, if it is a lowercase character, is title-cased, otherwise, it is left unmodified. Then, get/set/is is prefixed.
+		</p><p>
+			No method is generated if any method already exists with the same name (case insensitive) and same parameter count. For example, <code>getFoo()</code> will not be generated if there's already a method <code>getFoo(String... x)</code> even though it is technically possible to make the method. This caveat exists to prevent confusion. If the generation of a method is skipped for this reason, a warning is emitted instead. Varargs count as 0 to N parameters. You can mark any method with <code>@lombok.experimental.Tolerate</code> to hide them from lombok.
+		</p><p>
+			For <code>boolean</code> fields that start with <code>is</code> immediately followed by a title-case letter, nothing is prefixed to generate the getter name.
+		</p><p>
+			Any variation on <code>boolean</code> will <em>not</em> result in using the <code>is</code> prefix instead of the <code>get</code> prefix; for example, returning <code>java.lang.Boolean</code> results in a <code>get</code> prefix, not an <code>is</code> prefix.
+		</p><p>
+			Any annotations named <code>@NonNull</code> (case insensitive) on the 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 setter. Also, these annotations (as well as any annotation named <code>@Nullable</code> or <code>@CheckForNull</code>) are copied to setter parameter and getter method.
+		</p><p>
+			You can annotate a class with a <code>@Getter</code> or <code>@Setter</code> annotation. Doing so is equivalent to annotating all non-static fields in that class with that annotation. <code>@Getter</code>/<code>@Setter</code> annotations on fields take precedence over the ones on classes.
+		</p><p>
+			Using the <code>AccessLevel.NONE</code> access level simply generates nothing. It's useful only in combination with <a href="features/Data"><code>@Data</code></a> or a class-wide <code>@Getter</code> or <code>@Setter</code>.
+		</p><p>
+			<code>@Getter</code> can also be used on enums. <code>@Setter</code> can't, not for a technical reason, but for a pragmatic one: Setters on enums are an extremely bad idea.
+		</p>
+	</@f.smallPrint>
+</@f.scaffold>
diff --git a/website2/templates/features/NonNull.html b/website2/templates/features/NonNull.html
new file mode 100644
index 00000000..60879085
--- /dev/null
+++ b/website2/templates/features/NonNull.html
@@ -0,0 +1,43 @@
+<#import "_features.html" as f>
+
+<@f.scaffold title="@NonNull" logline="or: How I learned to stop worrying and love the NullPointerException.">
+	<@f.history>
+		<code>@NonNull</code> was introduced in lombok v0.11.10.
+	</@f.history>
+	
+	<@f.overview>
+		<p>
+			You can use <code>@NonNull</code> on the parameter of a method or constructor to have lombok generate a null-check statement for you.
+		</p><p>
+			Lombok has always treated any annotation named <code>@NonNull</code> on a field as a signal to generate a null-check if lombok generates an entire method or constructor for you, via for example <a href="/features/Data"><code>@Data</code></a>. Now, however, using lombok's own <code>@lombok.NonNull</code> on a parameter results in the insertion of just the null-check statement inside your own method or constructor.
+		</p><p>
+			The null-check looks like <code>if (param == null) throw new NullPointerException("param");</code> and will be inserted at the very top of your method. For constructors, the null-check will be inserted immediately following any explicit <code>this()</code> or <code>super()</code> calls.
+		</p><p>
+			If a null-check is already present at the top, no additional null-check will be generated.
+		</p>
+	</@f.overview>
+
+	<@f.snippets name="NonNull" />
+
+	<@f.confKeys>
+		<dt>
+			<code>lombok.nonNull.exceptionType</code> = [<code>NullPointerException</code> | <code>IllegalArgumentException</code>] (default: <code>NullPointerException</code>).
+		</dt><dd>
+			When lombok generates a null-check <code>if</code> statement, by default, a <code>java.lang.NullPointerException</code> will be thrown with the field name as the exception message. However, you can use <code>IllegalArgumentException</code> in this configuration key to have lombok throw that exception, with '<em>fieldName</em> is null' as exception message.
+		</dd><dt>
+			<code>lombok.nonNull.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
+		</dt><dd>
+			Lombok will flag any usage of <code>@NonNull</code> as a warning or error if configured.
+		</dd>
+	</@f.confKeys>
+
+	<@f.smallPrint>
+		<p>
+			Lombok's detection scheme for already existing null-checks consists of scanning for if statements that look just like lombok's own. Any 'throws' statement as the 'then' part of the if statement, whether in braces or not, counts. The conditional of the if statement <em>must</em> look exactly like <code>PARAMNAME == null</code>. The first statement in your method that is not such a null-check stops the process of inspecting for null-checks.
+		</p><p>
+			While <code>@Data</code> and other method-generating lombok annotations will trigger on any annotation named <code>@NonNull</code> regardless of casing or package name, this feature only triggers on lombok's own <code>@NonNull</code> annotation from the <code>lombok</code> package.
+		</p><p>
+			A <code>@NonNull</code> on a primitive parameter results in a warning. No null-check will be generated.
+		</p>
+	</@f.smallPrint>
+</@f.scaffold>
diff --git a/website2/templates/features/SneakyThrows.html b/website2/templates/features/SneakyThrows.html
new file mode 100644
index 00000000..5a2d5bbd
--- /dev/null
+++ b/website2/templates/features/SneakyThrows.html
@@ -0,0 +1,44 @@
+<#import "_features.html" as f>
+
+<@f.scaffold title="@SneakyThrows" logline="To boldly throw checked exceptions where no one has thrown them before!">
+	<@f.overview>
+		<p>
+			<code>@SneakyThrows</code> can be used to sneakily throw checked exceptions without actually declaring this in your method's <code>throws</code> clause. This somewhat contentious ability should be used carefully, of course. The code generated by lombok will not ignore, wrap, replace, or otherwise modify the thrown checked exception; it simply fakes out the compiler. On the JVM (class file) level, all exceptions, checked or not, can be thrown regardless of the <code>throws</code> clause of your methods, which is why this works.
+		</p><p>
+			Common use cases for when you want to opt out of the checked exception mechanism center around 2 situations:<br />
+			<ul>
+				<li>
+					A needlessly strict interface, such as <code>Runnable</code> - whatever exception propagates out of your <code>run()</code> method, checked or not, it will be passed to the <code>Thread</code>'s unhandled exception handler. Catching a checked exception and wrapping it in some sort of <code>RuntimeException</code> is only obscuring the real cause of the issue.
+				</li><li>
+					An 'impossible' exception. For example, <code>new String(someByteArray, "UTF-8");</code> declares that it can throw an <code>UnsupportedEncodingException</code> but according to the JVM specification, UTF-8 <em>must</em> always be available. An <code>UnsupportedEncodingException</code> here is about as likely as a <code>ClassNotFoundError</code> when you use a String object, and you don't catch those either!
+				</li>
+			</ul>
+		</p><p>
+			Be aware that it is <em>impossible</em> to catch sneakily thrown checked types directly, as javac will not let you write a catch block for an exception type that no method call in the try body declares as thrown. This problem is not relevant in either of the use cases listed above, so let this serve as a warning that you should not use the <code>@SneakyThrows</code> mechanism without some deliberation!
+		</p><p>
+			You can pass any number of exceptions to the <code>@SneakyThrows</code> annotation. If you pass no exceptions, you may throw any exception sneakily.
+		</p>
+	</@f.overview>
+
+	<@f.snippets name="SneakyThrows" />
+
+	<@f.confKeys>
+		<dt>
+			<code>lombok.sneakyThrows.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
+		</dt><dd>
+			Lombok will flag any usage of <code>@SneakyThrows</code> as a warning or error if configured.
+		</dd>
+	</@f.confKeys>
+
+	<@f.smallPrint>
+		<p>
+			Because <code>@SneakyThrows</code> is an implementation detail and not part of your method signature, it is an error if you try to declare a checked exception as sneakily thrown when you don't call any methods that throw this exception. (Doing so is perfectly legal for <code>throws</code> statements to accommodate subclasses). Similarly, <code>@SneakyThrows</code> does not inherit.
+		</p><p>
+			For the nay-sayers in the crowd: Out of the box, Eclipse will offer a 'quick-fix' for uncaught exceptions that wraps the offending statement in a try/catch block with just <code>e.printStackTrace()</code> in the catch block. This is so spectacularly non-productive compared to just sneakily throwing the exception onwards, that Roel and Reinier feel more than justified in claiming that the checked exception system is far from perfect, and thus an opt-out mechanism is warranted.
+		</p><p>
+			If you put <code>@SneakyThrows</code> on a constructor, any call to a sibling or super constructor is <em>excluded</em> from the <code>@SneakyThrows</code> treatment. This is a java restriction we cannot work around: Calls to sibling/super constructors MUST be the first statement in the constructor; they cannot be placed inside try/catch blocks.
+		</p><p>
+			<code>@SneakyThrows</code> on an empty method, or a constructor that is empty or only has a call to a sibling / super constructor results in no try/catch block and a warning.
+		</p>
+	</@f.smallPrint>
+</@f.scaffold>
diff --git a/website2/templates/features/Synchronized.html b/website2/templates/features/Synchronized.html
new file mode 100644
index 00000000..113add0e
--- /dev/null
+++ b/website2/templates/features/Synchronized.html
@@ -0,0 +1,34 @@
+<#import "_features.html" as f>
+
+<@f.scaffold title="@Synchronized" logline="<code>synchronized</code> done right: Don't expose your locks.">
+	<@f.overview>
+		<p>
+			<code>@Synchronized</code> is a safer variant of the <code>synchronized</code> method modifier. Like <code>synchronized</code>, the annotation can be used on static and instance methods only. It operates similarly to the <code>synchronized</code> keyword, but it locks on different objects. The keyword locks on <code>this</code>, but the annotation locks on a field named <code>$lock</code>, which is private.<br />
+			If the field does not exist, it is created for you. If you annotate a <code>static</code> method, the annotation locks on a static field named <code>$LOCK</code> instead.
+		</p><p>
+			If you want, you can create these locks yourself. The <code>$lock</code> and <code>$LOCK</code> fields will of course not be generated if you already created them yourself. You can also choose to lock on another field, by specifying it as parameter to the <code>@Synchronized</code> annotation. In this usage variant, the fields will not be created automatically, and you must explicitly create them yourself, or an error will be emitted.
+		</p><p>
+			Locking on <code>this</code> or your own class object can have unfortunate side-effects, as other code not under your control can lock on these objects as well, which can cause race conditions and other nasty threading-related bugs.
+		</p>
+	</@f.overview>
+
+	<@f.snippets name="Synchronized" />
+
+	<@f.confKeys>
+		<dt>
+			<code>lombok.synchronized.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
+		</dt><dd>
+			Lombok will flag any usage of <code>@Synchronized</code> as a warning or error if configured.
+		</dd>
+	</@f.confKeys>
+
+	<@f.smallPrint>
+		<p>
+			If <code>$lock</code> and/or <code>$LOCK</code> are auto-generated, the fields are initialized with an empty <code>Object[]</code> array, and not just a <code>new Object()</code> as most snippets showing this pattern in action use. Lombok does this because a new object is <em>NOT</em> serializable, but 0-size array is. Therefore, using <code>@Synchronized</code> will not prevent your object from being serialized.
+		</p><p>
+			Having at least one <code>@Synchronized</code> method in your class means there will be a lock field, but if you later remove all such methods, there will no longer be a lock field. That means your predetermined <code>serialVersionUID</code> changes. We suggest you <em>always</em> add a <code>serialVersionUID</code> to your classes if you intend to store them long-term via java's serialization mechanism. If you do so, removing all <code>@Synchronized</code> annotations from your method will not break serialization.
+		</p><p>
+			If you'd like to know why a field is not automatically generated when you choose your own name for the lock object: Because otherwise making a typo in the field name will result in a <em>very</em> hard to find bug!
+		</p>
+	</@f.smallPrint>
+</@f.scaffold>
diff --git a/website2/templates/features/ToString.html b/website2/templates/features/ToString.html
new file mode 100644
index 00000000..6f230561
--- /dev/null
+++ b/website2/templates/features/ToString.html
@@ -0,0 +1,54 @@
+<#import "_features.html" as f>
+
+<@f.scaffold title="@ToString" logline="No need to start a debugger to see your fields: Just let lombok generate a <code>toString</code> for you!">
+	<@f.overview>
+		<p>
+			Any class definition may be annotated with <code>@ToString</code> to let lombok generate an implementation of the <code>toString()</code> method. By default, it'll print your class name, along with each field, in order, separated by commas.
+		</p><p>
+			By setting the <code>includeFieldNames</code> parameter to <em>true</em> you can add some clarity (but also quite some length) to the output of the <code>toString()</code> method.
+		</p><p>
+			By default, all non-static fields will be printed. If you want to skip some fields, you can name them in the <code>exclude</code> parameter; each named field will not be printed at all. Alternatively, you can specify exactly which fields you wish to be used by naming them in the <code>of</code> parameter.
+		</p><p>
+			By setting <code>callSuper</code> to <em>true</em>, you can include the output of the superclass implementation of <code>toString</code> to the output. Be aware that the default implementation of <code>toString()</code> in <code>java.lang.Object</code> is pretty much meaningless, so you probably don't want to do this unless you are extending another class.
+		</p>
+	</@f.overview>
+
+	<@f.snippets name="ToString" />
+
+	<@f.confKeys>
+		<dt>
+			<code>lombok.toString.includeFieldNames</code> = [<code>true</code> | <code>false</code>] (default: true)
+		</dt><dd>
+			Normally lombok generates a fragment of the toString response for each field in the form of <code>fieldName = fieldValue</code>. If this setting is set to <code>false</code>, lombok will omit the name of the field and simply deploy a comma-separated list of all the field values. The annotation parameter '<code>includeFieldNames</code>', if explicitly specified, takes precedence over this setting.
+		</dd><dt>
+			<code>lombok.toString.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>toString</code> methods. The annotation parameter '<code>doNotUseGetters</code>', if explicitly specified, takes precedence over this setting.
+		</dd><dt>
+			<code>lombok.toString.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
+		</dt><dd>
+			Lombok will flag any usage of <code>@ToString</code> as a warning or error if configured.
+		</dd>
+	</@f.confKeys>
+
+	<@f.smallPrint>
+		<p>
+			If there is <em>any</em> method named <code>toString</code> with no arguments, regardless of return type, no method will be generated, and instead a warning is emitted explaining that your <code>@ToString</code> annotation is doing nothing. You can mark any method with <code>@lombok.experimental.Tolerate</code> to hide them from lombok.
+		</p><p>
+			Arrays are printed via <code>Arrays.deepToString</code>, 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>
+			Attempting to exclude fields that don't exist or would have been excluded anyway (because they are static) 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>
+			We don't promise to keep the output of the generated <code>toString()</code> methods the same between lombok versions. You should never design your API so that other code is forced to parse your <code>toString()</code> output anyway!
+		</p><p>
+			By default, any variables that start with a $ symbol are excluded automatically. You can only include them by using the 'of' parameter.