From 72fd50b9f1db1ab6bfc1753ba6a1e686a2f0f22c Mon Sep 17 00:00:00 2001 From: Reinier Zwitserloot Date: Mon, 8 May 2017 21:11:15 +0200 Subject: moved an update to the website text about the jdk8 onX support to the new website templates. --- website2/templates/features/experimental/onX.html | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'website2/templates/features/experimental') diff --git a/website2/templates/features/experimental/onX.html b/website2/templates/features/experimental/onX.html index 8e07f0ac..fd2e7b58 100644 --- a/website2/templates/features/experimental/onX.html +++ b/website2/templates/features/experimental/onX.html @@ -32,7 +32,9 @@

@Setter and @Wither support onParam in addition to onMethod; annotations listed will be put on the only parameter that the generated method has. @EqualsAndHashCode also supports onParam; the listed annotation(s) will be placed on the single parameter of the generated equals method, as well as any generated canEqual method.

- The syntax is a little strange; to use any of the 3 onX features, you must wrap the annotations to be applied to the constructor / method / parameter in @__(@AnnotationGoesHere). To apply multiple annotations, use @__({@Annotation1, @Annotation2}). The annotations can themselves obviously have parameters as well. + The syntax is a little strange and depends on the javac you are using.
+ On javac7, to use any of the 3 onX features, you must wrap the annotations to be applied to the constructor / method / parameter in @__(@AnnotationGoesHere). To apply multiple annotations, use @__({@Annotation1, @Annotation2}). The annotations can themselves obviously have parameters as well.
+ On javac8 and up, you add an underscore after onMethod, onParam, or onConstructor.

@@ -49,6 +51,8 @@ <@f.smallPrint>

The reason of the weird syntax is to make this feature work in javac 7 compilers; the @__ type is an annotation reference to the annotation type __ (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 __ type. Instead, lombok applies the annotations and removes the references so that the error will never actually occur. The point is: The __ type must not exist, otherwise the feature does not work. In the rare case that the __ 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. +

+ In javac8, the above feature should work but due to a bug in javac8 it does not. However, starting in javac8, if the parameter name does not exist in the annotation type, compilation proceeds to a phase where lombok can fix it.

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.

-- cgit