added docs for the new onParam feature on EqualsAndHashCode, and some tiny stylistic nitpicking.

1 files changed, 3 insertions, 3 deletions

diff --git a/website/features/experimental/onX.html b/website/features/experimental/onX.html
index 530d98a4..78537c67 100644
--- a/website/features/experimental/onX.html
+++ b/website/features/experimental/onX.html
@@ -15,7 +15,7 @@
 		<div class="since">
 			<h3>Since</h3>
 			<p>
-				onX was introduced as experimental feature in lombok v0.11.7 (<a href="/download-edge.html">edge release only</a>).
+				onX was introduced as experimental feature in lombok v0.11.8.
 			</p>
 		</div>
 		<div class="experimental">
@@ -40,7 +40,7 @@
 			</p><p>
 			<code>@AllArgsConstructor</code>, <code>@NoArgsConstructor</code>, and <code>@RequiredArgsConstructor</code> support the <code>onConstructor</code> option which will put the listed annotations on the generated constructor.
 			</p><p>
-			<code>@Setter</code> and <code>@Wither</code> support <code>onParam</code> in addition to <code>onMethod</code>; annotations listed will be put on the only parameter that the generated method has.
+			<code>@Setter</code> and <code>@Wither</code> support <code>onParam</code> in addition to <code>onMethod</code>; annotations listed will be put on the only parameter that the generated method has. <code>@EqualsAndHashCode</code> also supports <code>onParam</code>; the listed annotation(s) will be placed on the single parameter of the generated <code>equals</code> method, as well as any generated <code>canEqual</code> method.
 			</p><p>
 			The syntax is a little strange; to use any of the 3 <code>onX</code> features, you must wrap the annotations to be applied to the constructor / method / parameter in <code>@__(@AnnotationGoesHere)</code>. To apply multiple annotations, use <code>@__({@Annotation1, @Annotation2})</code>. The annotations can themselves obviously have parameters as well.
 			</p>
@@ -60,7 +60,7 @@
 		<div class="overview">
 			<h3>Small print</h3><div class="smallprint">
 				<p>
-				The reason of the weird syntax is to make this feature work in javac 7 compilers; the <code>@__</code> type is an annotation reference to the annotation type <code>_</code> (underscore) which doesn't actually exist; this makes javac 7 delay aborting the compilation process due to an error because it is possible an annotation processor will later create the <code>_</code> type. Instead, lombok applies the annotations and removes the references so that the error will never actually occur. The point is: The <code>_</code> type <em>must not exist</em>, otherwise the feature does not work. In the rare case that the <code>_</code> type does exist (and is imported or in the package), you can simply add more underscores. Technically any non-existent type would work, but to maintain consistency and readability and catch erroneous use, lombok considers it an error if the 'wrapper' annotation is anything but a series of underscores.
+				The reason of the weird syntax is to make this feature work in javac 7 compilers; the <code>@__</code> type is an annotation reference to the annotation type <code>__</code> (double underscore) which doesn't actually exist; this makes javac 7 delay aborting the compilation process due to an error because it is possible an annotation processor will later create the <code>__</code> type. Instead, lombok applies the annotations and removes the references so that the error will never actually occur. The point is: The <code>__</code> type <em>must not exist</em>, otherwise the feature does not work. In the rare case that the <code>__</code> type does exist (and is imported or in the package), you can simply add more underscores. Technically any non-existent type would work, but to maintain consistency and readability and catch erroneous use, lombok considers it an error if the 'wrapper' annotation is anything but a series of underscores.
 				</p><p>
 				To reiterate: This feature can disappear at any time; if you use this feature, be prepared to adjust your code when we find a nicer way of implementing this feature, or, if a future version of javac forces us to remove this feature entirely with no alternative.
 				</p><p>