diff options
| author | Reinier Zwitserloot <reinier@zwitserloot.com> | 2017-05-08 21:28:02 +0200 |
|---|---|---|
| committer | Reinier Zwitserloot <reinier@zwitserloot.com> | 2017-05-29 21:02:54 +0200 |
| commit | 8b7a7cbc813653a3248d6cf3a7779e220957bc85 (patch) | |
| tree | b9acfb9d68c6866acc3cfb9ee59d72ff43f1ebc3 /website2/templates/features | |
| parent | 72fd50b9f1db1ab6bfc1753ba6a1e686a2f0f22c (diff) | |
| download | lombok-8b7a7cbc813653a3248d6cf3a7779e220957bc85.tar.gz lombok-8b7a7cbc813653a3248d6cf3a7779e220957bc85.tar.bz2 lombok-8b7a7cbc813653a3248d6cf3a7779e220957bc85.zip | |
The great rename: the old ‘website’ is now ‘website-old’, and ‘website2’ is now ‘website’.
Diffstat (limited to 'website2/templates/features')
29 files changed, 0 insertions, 1763 deletions
diff --git a/website2/templates/features/Builder.html b/website2/templates/features/Builder.html deleted file mode 100644 index a6b8d18f..00000000 --- a/website2/templates/features/Builder.html +++ /dev/null @@ -1,163 +0,0 @@ -<#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<String> 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<T></code>, then the builder name will be <code>FancyListBuilder<T></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<Line> 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/website2/templates/features/BuilderSingular.html b/website2/templates/features/BuilderSingular.html deleted file mode 100644 index 10253365..00000000 --- a/website2/templates/features/BuilderSingular.html +++ /dev/null @@ -1,5 +0,0 @@ -<#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/website2/templates/features/Cleanup.html b/website2/templates/features/Cleanup.html deleted file mode 100644 index e868c40d..00000000 --- a/website2/templates/features/Cleanup.html +++ /dev/null @@ -1,35 +0,0 @@ -<#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/website2/templates/features/Data.html b/website2/templates/features/Data.html deleted file mode 100644 index 59370cc8..00000000 --- a/website2/templates/features/Data.html +++ /dev/null @@ -1,41 +0,0 @@ -<#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<T> { 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<Integer>(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/website2/templates/features/EqualsAndHashCode.html b/website2/templates/features/EqualsAndHashCode.html deleted file mode 100644 index 3c11367f..00000000 --- a/website2/templates/features/EqualsAndHashCode.html +++ /dev/null @@ -1,56 +0,0 @@ -<#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/website2/templates/features/GetterLazy.html b/website2/templates/features/GetterLazy.html deleted file mode 100644 index b1f374a8..00000000 --- a/website2/templates/features/GetterLazy.html +++ /dev/null @@ -1,31 +0,0 @@ -<#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 deleted file mode 100644 index 7ceaa3ba..00000000 --- a/website2/templates/features/GetterSetter.html +++ /dev/null @@ -1,70 +0,0 @@ -<#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 deleted file mode 100644 index 28d083d0..00000000 --- a/website2/templates/features/NonNull.html +++ /dev/null @@ -1,45 +0,0 @@ -<#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><p> - A <code>@NonNull</code> on a parameter of an abstract method used to generate a warning; starting with version 1.16.8, this is no longer the case, to acknowledge the notion that <code>@NonNull</code> also has a documentary role. For the same reason, you can annotate a method as <code>@NonNull</code>; this is allowed, generates no warning, and does not generate any code. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/SneakyThrows.html b/website2/templates/features/SneakyThrows.html deleted file mode 100644 index 5a2d5bbd..00000000 --- a/website2/templates/features/SneakyThrows.html +++ /dev/null @@ -1,44 +0,0 @@ -<#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 deleted file mode 100644 index 113add0e..00000000 --- a/website2/templates/features/Synchronized.html +++ /dev/null @@ -1,34 +0,0 @@ -<#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 deleted file mode 100644 index 6f230561..00000000 --- a/website2/templates/features/ToString.html +++ /dev/null @@ -1,54 +0,0 @@ -<#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. - </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>@ToString(doNotUseGetters = true)</code> - </p><p> - <code>@ToString</code> can also be used on an enum definition. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/Value.html b/website2/templates/features/Value.html deleted file mode 100644 index fdad0e12..00000000 --- a/website2/templates/features/Value.html +++ /dev/null @@ -1,50 +0,0 @@ -<#import "_features.html" as f> - -<@f.scaffold title="@Value" logline="Immutable classes made very easy."> - <@f.history> - <p> - <code>@Value</code> was introduced as experimental feature in lombok v0.11.4. - </p><p> - <code>@Value</code> no longer implies <code>@Wither</code> since lombok v0.11.8. - </p><p> - <code>@Value</code> promoted to the main <code>lombok</code> package since lombok v0.12.0. - </p> - </@f.history> - - <@f.overview> - <p> - <code>@Value</code> is the immutable variant of <a href="/features/Data"><code>@Data</code></a>; all fields are made <code>private</code> and <code>final</code> by default, and setters are not generated. The class itself is also made <code>final</code> by default, because immutability is not something that can be forced onto a subclass. Like <code>@Data</code>, useful <code>toString()</code>, <code>equals()</code> and <code>hashCode()</code> methods are also generated, each field gets a getter method, and a constructor that covers every argument (except <code>final</code> fields that are initialized in the field declaration) is also generated. - </p><p> - In practice, <code>@Value</code> is shorthand for: <code>final @ToString @EqualsAndHashCode @AllArgsConstructor @FieldDefaults(makeFinal = true, level = AccessLevel.PRIVATE) @Getter</code>, except that explicitly including an implementation of any of the relevant methods simply means that part won't be generated and no warning will be emitted. For example, if you write your own <code>toString</code>, no error occurs, and lombok will not generate a <code>toString</code>. Also, <em>any</em> explicit constructor, no matter the arguments list, implies lombok will not generate a constructor. If you do want lombok to generate the all-args constructor, add <code>@AllArgsConstructor</code> to the class. You can mark any constructor or method with <code>@lombok.experimental.Tolerate</code> to hide them from lombok. - </p><p> - It is possible to override the final-by-default and private-by-default behavior using either an explicit access level on a field, or by using the <code>@NonFinal</code> or <code>@PackagePrivate</code> annotations.<br /> - It is possible to override any default behavior for any of the 'parts' that make up <code>@Value</code> by explicitly using that annotation. - </p> - </@f.overview> - - <@f.snippets name="Value" /> - - <@f.confKeys> - <dt> - <code>lombok.value.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@Value</code> as a warning or error if configured. - </dd><dt> - <code>lombok.val.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>val</code> as a warning or error if configured. - </dd> - </@f.confKeys> - - <@f.smallPrint> - <p> - Look for the documentation on the 'parts' of <code>@Value</code>: <a href="/features/ToString"><code>@ToString</code></a>, <a href="/features/EqualsAndHashCode"><code>@EqualsAndHashCode</code></a>, <a href="/features/Constructor"><code>@AllArgsConstructor</code></a>, <a href="/features/experimental/FieldDefaults"><code>@FieldDefaults</code></a>, and <a href="/features/GetterSetter"><code>@Getter</code></a>. - </p><p> - For classes with generics, it's useful to have a static method which serves as a constructor, because inference of generic parameters via static methods works in java6 and avoids having to use the diamond operator. While you can force this by applying an explicit <code>@AllArgsConstructor(staticConstructor="of")</code> annotation, there's also the <code>@Value(staticConstructor="of")</code> feature, which will make the generated all-arguments constructor private, and generates a public static method named <code>of</code> which is a wrapper around this private constructor. - </p><p> - <code>@Value</code> was an experimental feature from v0.11.4 to v0.11.9 (as <code>@lombok.experimental.Value</code>). It has since been moved into the core package. The old annotation is still around (and is an alias). It will eventually be removed in a future version, though. - </p><p> - It is not possible to use <code>@FieldDefaults</code> to 'undo' the private-by-default and final-by-default aspect of fields in the annotated class. Use <code>@NonFinal</code> and <code>@PackagePrivate</code> on the fields in the class to override this behaviour. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/_features.html b/website2/templates/features/_features.html deleted file mode 100644 index d7c75761..00000000 --- a/website2/templates/features/_features.html +++ /dev/null @@ -1,79 +0,0 @@ -<#import "/_scaffold.html" as main> - -<#macro featureSection> - <div class="row"> - <#nested> - </div> -</#macro> - -<#macro history> - <div class="row"> - <#nested> - </div> -</#macro> - -<#macro overview> - <div class="row"> - <h3>Overview</h3> - <#nested> - </div> -</#macro> - -<#macro experimental> - <div class="row"> - <h3>Experimental</h3> - - Experimental because: - <#nested> - </div> -</#macro> - -<#macro snippets name> - <div class="row container-fluid"> - <div class="col-lg-6"> - <h3>With Lombok</h3> - - <div class="snippet">${usages.pre(name)?no_esc}</div> - </div> - <div class="sep"></div> - <div class="col-lg-6"> - <h3>Vanilla Java</h3> - - <div class="snippet">${usages.post(name)?no_esc}</div> - </div> - </div> -</#macro> - -<#macro confKeys> - <div class="row"> - <h3>Supported configuration keys:</h3> - <dl> - <#nested> - </dl> - </div> -</#macro> - -<#macro smallPrint> - <div class="row"> - <h3>Small print</h3> - - <div class="smallprint"> - <#nested> - </div> - </div> -</#macro> - -<#macro scaffold title logline load=[]> - <@main.scaffold load> - <div class="page-header top5" id="featureContent"> - <div class="row text-center"> - <div class="header-group"> - <h1>${title}</h1> - - <h3>${logline}</h3> - </div> - </div> - <#nested> - </div> - </@main.scaffold> -</#macro> diff --git a/website2/templates/features/configuration.html b/website2/templates/features/configuration.html deleted file mode 100644 index d33ae1c5..00000000 --- a/website2/templates/features/configuration.html +++ /dev/null @@ -1,106 +0,0 @@ -<#import "_features.html" as f> - -<@f.scaffold title="Configuration system" logline="Lombok, made to order: Configure lombok features in one place for your entire project or even your workspace."> - <@f.history> - The configuration system was introduced in lombok 1.14. - </@f.history> - - <@f.overview> - <p> - You can create <code>lombok.config</code> files in any directory and put configuration directives in it. These apply to all source files in this directory and all child directories.<br /> - The configuration system is particularly useful for configurable aspects of lombok which tend to be the same across an entire project, such as the name of your log variable. The configuration system can also be used to tell lombok to flag any usage of some lombok feature you don't like as a warning or even an error. - </p><p> - Usually, a user of lombok puts a <code>lombok.config</code> file with their preferences in a workspace or project root directory, with the special <code>config.stopBubbling = true</code> key to tell lombok this is your root directory. You can then create <code>lombok.config</code> files in any subdirectories (generally representing projects or source packages) with different settings. - </p><p> - An up to date list of all configuration keys supported by your version of lombok can be generated by running: - <div class="snippet example"> - <code>java -jar lombok.jar config -g --verbose</code> - </div> - The output of the <em>config</em> tool is itself a valid <code>lombok.config</code> file.<br /> - The <em>config</em> tool can also be used to display the complete lombok configuration used for any given directory or source file by supplying these as arguments. - </p><p> - A sample of available configuration options (see the feature pages of the lombok features for their related config keys, as well as <code>java -jar lombok.jar config -g</code> for the complete list): - <dl> - <dt> - <code>lombok.accessors.chain</code> - </dt><dd> - If set to <code>true</code>, generated setters will 'chain' by default (They will return <code>this</code> instead of having a <code>void</code> return type). - </dd><dt> - <code>lombok.accessors.fluent</code> - </dt><dd> - If set to <code>true</code>, generated setters and getters will simply be named the same as the field name, without a <code>get</code> or <code>set</code> prefix. - </dd><dt> - <code>lombok.anyConstructor.suppressConstructorProperties</code> - </dt><dd> - If <code>true</code>, lombok will not generate a <code>@java.beans.ConstructorProperties</code> annotation when generating constructors. This is particularly useful for GWT and Android development. - </dd><dt> - <code>lombok.log.fieldName</code> - </dt><dd> - The name of the generated log field (default: <code>log</code>). - </dd><dt> - <code>lombok.<em>(featureName)</em>.flagUsage</code> - </dt><dd> - Allows you to forcibly stop or discourage use of a lombok feature. Legal values for this key are <code>warning</code> or <code>error</code>. Some examples of values for <em>(featureName)</em> are: "<code>experimental</code>" (flags use of any of the <a href="/features/experimental">experimental</a> features)</li>, "<a href="/features/Builder"><code>builder</code></a>", "<a - href="/features/SneakyThrows"><code>sneakyThrows</code></a>", or "<a href="/features/experimental/ExtensionMethod"><code>extensionMethod</code></a>". - </dd> - </dl> - </p><p> - Configuration files are hierarchical: Any configuration setting applies to all source files in that directory, and all source files in subdirectories, but configuration settings closer to the source file take precedence. For example, if you have in <code>/Users/me/projects/lombok.config</code> the following: - <div class="snippet example"> - <code>lombok.log.fieldName = foobar</code> - </div> - and in <code>/Users/me/projects/MyProject/lombok.config</code> you have: - <div class="snippet example"> - <code>lombok.log.fieldName = xyzzy</code> - </div> - Then the various <a ng-click="toFeature('log')"><code>@Log</code></a> annotations will use <code>foobar</code> instead of the default <code>log</code> as a field name to generate in all your projects, except for your project in <code>/Users/me/projects/MyProject</code>, where <code>xyzzy</code> is used instead. - </p><p> - To restore a configuration key set by a parent config file back to the default, the <code>clear</code> option can be used. For example, if a parent configuration file has configured all use of <code>val</code> to emit a warning, you can turn off the warnings for a subdirectory by including in it a <code>lombok.config</code> file with: - <div class="snippet example"> - <code>clear lombok.val.flagUsage</code> - </div> - </p><p> - Some configuration keys take lists. For lists, use <code>+=</code> to add an entry. You can remove a single item from the list (useful to undo a parent configuration file's setting) with <code>-=</code>. For example: - <div class="snippet example"> - <code>lombok.accessors.prefix += m_</code> - </div> - </p><p> - Comments can be included in <code>lombok.config</code> files; any line that starts with <code>#</code> is considered a comment. - </p> - </@f.overview> - - <@f.featureSection> - <h3>Global config keys</h3> - - <p> - To stop lombok from looking at parent directories for more configuration files, the special key: - <div class="snippet example"> - <code>config.stopBubbling = true</code> - </div> - can be included. We suggest you put this in the root of your workspace directory. - </p><p> - Lombok normally adds <code>@javax.annotation.Generated</code> annotations to all generated nodes where possible. You can stop this with: - <div class="snippet example"> - <code>lombok.addGeneratedAnnotation = false</code> - </div> - </p><p> - Lombok can add the <code>@SuppressFBWarnings</code> annotation which is useful if you want to run <a href="http://findbugs.sourceforge.net/">FindBugs</a> on your class files. To enable this feature, make sure findbugs is on the classpath when you compile, and add the following config key: - <div class="snippet example"> - <code>lombok.extern.findbugs.addSuppressFBWarnings = true</code> - </div> - </p> - </@f.featureSection> - - <@f.featureSection> - <h3>Config keys that can affect any source file</h3> - - <p> - These config keys can make lombok affect source files even if they have 0 lombok annotations in them.<br /> - <div class="snippet example"> - <code>lombok.fieldDefaults.defaultPrivate = true</code><br /> - <code>lombok.fieldDefaults.defaultFinal = true</code> - </div> - Turning either of these options on means lombok will make <em>every</em> field in <em>every</em> source file final and/or private unless it has an explicit access modifier or annotation to suppress this. <a href="experimental/FieldDefaults">See the <code>@FieldDefaults</code> documentation for more</a>. - </p> - </@f.featureSection> -</@f.scaffold> diff --git a/website2/templates/features/constructor.html b/website2/templates/features/constructor.html deleted file mode 100644 index 6a12fa2a..00000000 --- a/website2/templates/features/constructor.html +++ /dev/null @@ -1,57 +0,0 @@ -<#import "_features.html" as f> - -<@f.scaffold title="@NoArgsConstructor, @RequiredArgsConstructor, @AllArgsConstructor" - logline="Constructors made to order: Generates constructors that take no arguments, one argument per final / non-null field, or one argument for every field."> - - <@f.overview> - <p> - This set of 3 annotations generate a constructor that will accept 1 parameter for certain fields, and simply assigns this parameter to the field. - </p><p> - <code>@NoArgsConstructor</code> will generate a constructor with no parameters. If this is not possible (because of final fields), a compiler error will result instead, unless <code>@NoArgsConstructor(force = true</code> is used, then all final fields are initialized with <code>0</code> / <code>false</code> / <code>null</code>. For fields with constraints, such as <code>@NonNull</code> fields, <em>no</em> check is generated,so be aware that these constraints will generally not be fulfilled until those fields are properly initialized later. Certain java constructs, such as hibernate and the Service Provider Interface require a no-args constructor. This annotation is useful primarily in combination with either <code>@Data</code> or one of the other constructor generating annotations. - </p><p> - <code>@RequiredArgsConstructor</code> generates a constructor with 1 parameter for each field that requires special handling. All non-initialized <code>final</code> fields get a parameter, as well as any fields that are marked as <code>@NonNull</code> that aren't initialized where they are declared. For those fields marked with <code>@NonNull</code>, an explicit null check is also generated. The constructor will throw a <code>NullPointerException</code> if any of the parameters intended for the fields marked with <code>@NonNull</code> contain <code>null</code>. The order of the parameters match the order in which the fields appear in your class. - </p><p> - <code>@AllArgsConstructor</code> generates a constructor with 1 parameter for each field in your class. Fields marked with <code>@NonNull</code> result in null checks on those parameters. - </p><p> - Each of these annotations allows an alternate form, where the generated constructor is always private, and an additional static factory method that wraps around the private constructor is generated. This mode is enabled by supplying the <code>staticName</code> value for the annotation, like so: <code>@RequiredArgsConstructor(staticName="of")</code>. Such a static factory method will infer generics, unlike a normal constructor. This means your API users get write <code>MapEntry.of("foo", 5)</code> instead of the much longer <code>new MapEntry<String, Integer>("foo", 5)</code>. - </p><p> - To put annotations on the generated constructor, you can use <code>onConstructor=@__({@AnnotationsHere})</code>, but be careful; this is an experimental feature. For more details see the documentation on the <a href="/features/experimental/onX">onX</a> feature. - </p><p> - Static fields are skipped by these annotations. Also, a <code>@java.beans.ConstructorProperties</code> annotation is added for all constructors with at least 1 argument, which allows bean editor tools to call the generated constructors. <code>@ConstructorProperties</code> is new in Java 1.6, which means that if your code is intended for compilation on Java 1.5, a compiler error will occur. <em>Running</em> on a JVM 1.5 should be no problem (the annotation will be ignored). To suppress the generation of the <code>@ConstructorProperties</code> annotation, add a parameter to your annotation: <code>@AllArgsConstructor(suppressConstructorProperties=true)</code>. However, as java 1.5, which has already been end-of-lifed, fades into obscurity, this parameter will eventually be removed. It has also been marked deprecated for this reason. - </p><p> - Unlike most other lombok annotations, the existence of an explicit constructor does not stop these annotations from generating their own constructor. This means you can write your own specialized constructor, and let lombok generate the boilerplate ones as well. If a conflict arises (one of your constructors ends up with the same signature as one that lombok generates), a compiler error will occur. - </p> - </@f.overview> - - <@f.snippets name="Constructor" /> - - <@f.confKeys> - <dt> - <code>lombok.anyConstructor.suppressConstructorProperties</code> = [<code>true</code> | <code>false</code>] (default: <code>false</code>) - </dt><dd> - If set to <code>true</code>, then lombok will skip adding a <code>@java.beans.ConstructorProperties</code> to generated constructors. This is useful in android and GWT development where that annotation is not usually available. - </dd><dt> - <code>lombok.</code>[<code>allArgsConstructor</code>|<code>requiredArgsConstructor</code>|<code>noArgsConstructor</code>]<code>.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of the relevant annotation (<code>@AllArgsConstructor</code>, <code>@RequiredArgsConstructor</code> or <code>@NoArgsConstructor</code>) as a warning or error if configured. - </dd><dt> - <code>lombok.anyConstructor.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of any of the 3 constructor-generating annotations as a warning or error if configured. - </dd> - </@f.confKeys> - - <@f.smallPrint> - <p> - Even if a field is explicitly initialized with <code>null</code>, lombok will consider the requirement to avoid null as fulfilled, and will <em>NOT</em> consider the field as a 'required' argument. The assumption is that if you explicitly assign <code>null</code> to a field that you've also marked as <code>@NonNull</code> signals you must know what you're doing. - </p><p> - The <code>@java.beans.ConstructorProperties</code> annotation is never generated for a constructor with no arguments. This also explains why <code>@NoArgsConstructor</code> lacks the <code>suppressConstructorProperties</code> annotation method. The generated static factory methods also do not get <code>@ConstructorProperties</code>, as this annotation can only be added to real constructors. - </p><p> - <code>@XArgsConstructor</code> can also be used on an enum definition. The generated constructor will always be private, because non-private constructors aren't legal in enums. You don't have to specify <code>AccessLevel.PRIVATE</code>. - </p><p> - While <code>suppressConstructorProperties</code> has been marked deprecated in anticipation of a world where all java environments have the <code>@ConstructorProperties</code> annotation available, first GWT 2.2 and Android 2.3.3, which do not (yet) have this annotation, will have to be ancient history before this annotation parameter will be removed. - </p><p> - The <code>flagUsage</code> configuration keys do not trigger when a constructor is generated by <code>@Data</code>, <code>@Value</code> or any other lombok annotation. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/delombok.html b/website2/templates/features/delombok.html deleted file mode 100644 index fc9dfddc..00000000 --- a/website2/templates/features/delombok.html +++ /dev/null @@ -1,61 +0,0 @@ -<#import "_features.html" as f> - -<@f.scaffold title="Delombok" logline=""> - <@f.overview> - <p> - Normally, lombok adds support for all the lombok features directly to your IDE and compiler by plugging into them.<br /> - However, lombok doesn't cover all tools. For example, lombok cannot plug into javadoc, nor can it plug into the Google Widget Toolkit, both of which run on java sources. Delombok still allows you to use lombok with these tools by preprocessing your java code into java code with all of lombok's transformations already applied. - </p><p> - Delombok can of course also help understand what's happening with your source by letting you look at exactly what lombok is doing 'under the hood'. - </p><p> - Delombok's standard mode of operation is that it copies an entire directory into another directory, recursively, skipping class files, and applying lombok transformations to any java source files it encounters. - </p><p> - Delombok's output format can be configured with command line options (use <code>--format-help</code> for a complete list). A few such options are automatically scanned from input if possible (such as indent). If delombok's formatting is not conforming to your preferred code style, have a look! - </p> - - <h3>Running delombok on the command line</h3> - - <p> - Delombok is included in <code>lombok.jar</code>. To use it, all you need to run on the command line is: - <div class="snippet"> - <pre>java -jar lombok.jar delombok src -d src-delomboked</pre> - </div><br /> - Which will duplicate the contents of the <code>src</code> directory into the <code>src-delomboked</code> directory, which will be created if it doesn't already exist, but delomboked of course. Delombok on the command line has a few more options; use the <code>--help</code> parameter to see more options. - </p><p> - To let delombok print the transformation result of a single java file directly to standard output, you can use: - <div class="snippet"> - <pre>java -jar lombok.jar delombok -p MyJavaFile.java</pre> - </div> - </p> - - <h3>Running delombok in ant</h3> - - <p> - <code>lombok.jar</code> includes an ant task which can apply delombok for you. For example, to create javadoc for your project, your <code>build.xml</code> file would look something like: - <div class="snippet"><pre><target name="javadoc"> -<taskdef classname="lombok.delombok.ant.Tasks$Delombok" classpath="lib/lombok.jar" name="delombok" /> -<mkdir dir="build/src-delomboked" /> -<strong><delombok verbose="true" encoding="UTF-8" to="build/src-delomboked" from="src"></strong> - <strong><format value="suppressWarnings:skip" /></strong> -<strong></delombok></strong> -<mkdir dir="build/api" /> -<javadoc sourcepath="build/src-delomboked" defaultexcludes="yes" destdir="build/api" /> -</target></pre> - </div><br /> - Instead of a <code>from</code> attribute, you can also nest <code><fileset></code> nodes. - </p> - - <h3>Running delombok in maven</h3> - - <p> - Anthony Whitford has written a <a href="https://github.com/awhitford/lombok.maven">maven plugin</a> for delomboking your source code. - </p> - - <h3>Limitations</h3> - - <p> - Delombok tries to preserve your code as much as it can, but comments may move around a little bit, especially comments that are in the middle of a syntax node. For example, any comments appearing in the middle of a list of method modifiers, such as <code>public /*comment*/ static ...</code> will move towards the front of the list of modifiers. In practice, any java source parsing tool will not be affected.<br /> - To keep any changes to your code style to a minimum, delombok just copies a source file directly without changing any of it if the source file contains no lombok transformations. - </p> - </@f.overview> -</@f.scaffold> diff --git a/website2/templates/features/experimental/Accessors.html b/website2/templates/features/experimental/Accessors.html deleted file mode 100644 index 97017dc6..00000000 --- a/website2/templates/features/experimental/Accessors.html +++ /dev/null @@ -1,75 +0,0 @@ -<#import "../_features.html" as f> - -<@f.scaffold title="@Accessors" logline="A more fluent API for getters and setters."> - <@f.history> - <p> - <code>@Accessors</code> was introduced as experimental feature in lombok v0.11.0. - </p> - </@f.history> - - <@f.experimental> - <ul> - <li> - We may want to roll these features into a more complete property support concept. - </li><li> - New feature – community feedback requested. - </li> - </ul> - Current status: <em>positive</em> - Currently we feel this feature may move out of experimental status with no or minor changes soon. - </@f.experimental> - - <@f.overview> - <p> - The <code>@Accessors</code> annotation is used to configure how lombok generates and looks for getters and setters. - </p><p> - By default, lombok follows the <em>bean specification</em> for getters and setters: The getter for a field named <code>pepper</code> is <code>getPepper</code> for example. However, some might like to break with the <em>bean specification</em> in order to end up with nicer looking APIs. <code>@Accessors</code> lets you do this. - </p><p> - Some programmers like to use a prefix for their fields, i.e. they write <code>fPepper</code> instead of <code>pepper</code>. We <em>strongly</em> discourage doing this, as you can't unit test the validity of your prefixes, and refactor scripts may turn fields into local variables or method names. Furthermore, your tools (such as your editor) can take care of rendering the identifier in a certain way if you want this information to be instantly visible. Nevertheless, you can list the prefixes that your project uses via <code>@Accessors</code> as well. - </p><p> - <code>@Accessors</code> therefore has 3 options: - <ul> - <li> - <code>fluent</code> – A boolean. If <em>true</em>, the getter for <code>pepper</code> is just <code>pepper()</code>, and the setter is <code>pepper(T newValue)</code>. Furthermore, unless specified, <code>chain</code> defaults to <em>true</em>. <br /> - Default: <em>false</em>. - </li><li> - <code>chain</code> – A boolean. If <em>true</em>, generated setters return <code>this</code> instead of <code>void</code>.<br /> - Default: <em>false</em>, unless <code>fluent=true</code>, then Default: <em>true</em>. - </li><li> - <code>prefix</code> – A list of strings. If present, fields must be prefixed with any of these prefixes. Each field name is compared to each prefix in the list in turn, and if a match is found, the prefix is stripped out to create the base name for the field. It is legal to include an empty string in the list, which will always match. For characters which are letters, the character following the prefix must not be a lowercase letter, i.e. <code>pepper</code> is not a match even to prefix <code>p</code>, but <code>pEpper</code> would be (and would mean the base name of this field is <code>epper</code>). - </li> - </ul> - <p><p> - The <code>@Accessors</code> annotation is legal on types and fields; the annotation that applies is the one on the field if present, otherwise the one on the class. When a <code>@Accessors</code> annotation on a field is present, any <code>@Accessors</code> annotation also present on that field's type is ignored. - </p> - </@f.overview> - - <@f.snippets name="experimental/Accessors" /> - - <@f.confKeys> - <dt> - <code>lombok.accessors.chain</code> = [<code>true</code> | <code>false</code>] (default: false) - </dt><dd> - If set to <code>true</code>, any class that either doesn't have an <code>@Accessors</code> annotation, or it does, but that annotation does not have an explicit value for the <code>chain</code> parameter, will act as if <code>@Accessors(chain = true)</code> is present. - </dd><dt> - <code>lombok.accessors.fluent</code> = [<code>true</code> | <code>false</code>] (default: false) - </dt><dd> - If set to <code>true</code>, any class that either doesn't have an <code>@Accessors</code> annotation, or it does, but that annotation does not have an explicit value for the <code>fluent</code> parameter, will act as if <code>@Accessors(fluent = true)</code> is present. - </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. Any class that either doesn't have an <code>@Accessors</code> annotation, or it does, but that annotation does not have an explicit value for the <code>prefix</code> parameter, will act as if <code>@Accessors(prefix = {<em>prefixes listed in configuration</em>})</code> is present. - </dd><dt> - <code>lombok.accessors.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@Accessors</code> as a warning or error if configured. - </dd> - </@f.confKeys> - - <@f.smallPrint> - <p> - The nearest <code>@Accessors</code> annotation is also used for the various methods in lombok that look for getters, such as <code>@EqualsAndHashCode</code>. - </p><p> - If a prefix list is provided and a field does not start with one of them, that field is skipped entirely by lombok, and a warning will be generated. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/experimental/Delegate.html b/website2/templates/features/experimental/Delegate.html deleted file mode 100644 index 265c754a..00000000 --- a/website2/templates/features/experimental/Delegate.html +++ /dev/null @@ -1,59 +0,0 @@ -<#import "../_features.html" as f> - -<@f.scaffold title="@Delegate" logline="Don't lose your composition."> - <@f.history> - <p> - <code>@Delegate</code> was introduced as feature in lombok v0.10 (the experimental package did not exist yet).<br /> - It was moved to the experimental package in lombok v1.14; the old version from the main lombok package is now deprecated. - </p> - </@f.history> - - <@f.experimental> - <ul> - <li> - Not used that much. - </li><li> - Difficult to support for edge cases, such as recursive delegation. - </li><li> - API is rather unfriendly; it would be a lot nicer if you can simply implement some methods and let <code>@Delegate</code> generate delegates for whatever you didn't manually implement, but due to issues with generics erasure this also can't be made to work without caveats. - </li> - </ul> - Current status: <em>negative</em> - Currently we feel this feature will not move out of experimental status anytime soon, and support for this feature may be dropped if future versions of javac or ecj make it difficult to continue to maintain the feature. - </@f.experimental> - - <@f.overview> - <p> - Any field or no-argument method can be annotated with <code>@Delegate</code> to let lombok generate delegate methods that forward the call to this field (or the result of invoking this method). - </p><p> - Lombok delegates all <code>public</code> methods of the field's type (or method's return type), as well as those of its supertypes except for all methods declared in <code>java.lang.Object</code>. - </p><p> - You can pass any number of classes into the <code>@Delegate</code> annotation's <code>types</code> parameter. If you do that, then lombok will delegate all <code>public</code> methods in those types (and their supertypes, except <code>java.lang.Object</code>) instead of looking at the field/method's type. - </p><p> - All public non-<code>Object</code> methods that are part of the calculated type(s) are copied, whether or not you also wrote implementations for those methods. That would thus result in duplicate method errors. You can avoid these by using the <code>@Delegate(excludes=SomeType.class)</code> parameter to exclude all public methods in the excluded type(s), and their supertypes. - </p><p> - To have very precise control over what is delegated and what isn't, write private inner interfaces with method signatures, then specify these private inner interfaces as types in <code>@Delegate(types=PrivateInnerInterfaceWithIncludesList.class, excludes=SameForExcludes.class)</code>. - </p> - </@f.overview> - - <@f.snippets name="experimental/Delegate" /> - - <@f.confKeys> - <dt> - <code>lombok.delegate.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@Delegate</code> as a warning or error if configured. - </dd> - </@f.confKeys> - - <@f.smallPrint> - <p> - When passing classes to the annotation's <code>types</code> or <code>excludes</code> parameter, you cannot include generics. This is a limitation of java. Use private inner interfaces or classes that extend the intended type including the generics parameter to work around this problem. - </p><p> - When passing classes to the annotation, these classes do not need to be supertypes of the field. See the example. - </p><p> - <code>@Delegate</code> cannot be used on static fields or methods. - </p><p> - <code>@Delegate</code> cannot be used when the calculated type(s) to delegate / exclude themselves contain <code>@Delegate</code> annotations; in other words, <code>@Delegate</code> will error if you attempt to use it recursively. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/experimental/ExtensionMethod.html b/website2/templates/features/experimental/ExtensionMethod.html deleted file mode 100644 index ca63bb2e..00000000 --- a/website2/templates/features/experimental/ExtensionMethod.html +++ /dev/null @@ -1,67 +0,0 @@ -<#import "../_features.html" as f> - -<@f.scaffold title="@ExtensionMethod" logline="Annoying API? Fix it yourself: Add new methods to existing types!"> - <@f.history> - <p> - <code>@ExtensionMethod</code> was introduced as experimental feature in lombok v0.11.2. - </p> - </@f.history> - - <@f.experimental> - <ul> - <li> - High-impact on code style. - </li><li> - Really would like to ship with utility methods to expand common classes, but so far lombok doesn't have a good distribution method for such runtime dependencies. - </li><li> - Affects quite a bit of eclipse, and auto-complete e.d. do not work yet in netbeans. - </li><li> - Should @ExtensionMethod be legal on methods? Should it be legal on packages? - </li><li> - This feature has more bugs associated with it than we would like, and it is a large maintenance burden. - </li> - </ul> - Current status: <em>hold</em> - Currently we feel this feature will not move out of experimental status anytime soon, but it will not significantly change and support for it is unlikely to be removed in future versions of lombok either. - </@f.experimental> - - <@f.overview> - <p> - You can make a class containing a bunch of <code>public</code>, <code>static</code> methods which all take at least 1 parameter. These methods will extend the type of the first parameter, as if they were instance methods, using the <code>@ExtensionMethod</code> feature. - </p><p> - For example, if you create <code>public static String toTitleCase(String in) { ... }</code>, you can use the <code>@ExtensionMethod</code> feature to make it look like the <code>java.lang.String</code> class has a method named <code>toTitleCase</code>, which has no arguments. The first argument of the static method fills the role of <code>this</code> in instance methods. - </p><p> - All methods that are <code>public</code>, <code>static</code>, and have at least 1 argument whose type is not primitive, are considered extension methods, and each will be injected into the namespace of the type of the first parameter as if they were instance methods. As in the above example, a call that looks like: <code>foo.toTitleCase()</code> is replaced with <code>ClassContainingYourExtensionMethod.toTitleCase(foo);</code>. Note that it is actually not an instant <code>NullPointerException</code> if <code>foo</code> is null - it is passed like any other parameter. - </p><p> - You can pass any number of classes to the <code>@ExtensionMethod</code> annotation; they will all be searched for extension methods. These extension methods apply for any code that is in the annotated class. - </p><p> - Lombok does not (currently) have any runtime dependencies which means lombok does not (currently) ship with any useful extension methods so you'll have to make your own. However, here's one that might spark your imagination: <br /> - <pre>public class ObjectExtensions { - public static <T> or(T object, T ifNull) { - return object != null ? object : ifNull; - } -}</pre><br /> - With the above class, if you add <code>@ExtensionMethod(ObjectExtensions.class)</code> to your class definition, you can write:<br /> - <pre>String x = null; -System.out.println(x.or("Hello, World!"));</pre><br /> - The above code will not fail with a <code>NullPointerException</code>; it will actually output <code>Hello, World!</code> - </p> - </@f.overview> - - <@f.snippets name="experimental/ExtensionMethod" /> - - <@f.confKeys> - <dt> - <code>lombok.extensionMethod.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@ExtensionMethod</code> as a warning or error if configured. - </dd> - </@f.confKeys> - - <@f.smallPrint> - <p> - Calls are rewritten to a call to the extension method; the static method itself is not inlined. Therefore, the extension method must be present both at compile and at runtime. - </p><p> - Generics is fully applied to figure out extension methods. i.e. if the first parameter of your extension method is <code>List<? extends String></code>, then any expression that is compatible with that will have your extension method, but other kinds of lists won't. So, a <code>List<Object></code> won't get it, but a <code>List<String></code> will. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/experimental/FieldDefaults.html b/website2/templates/features/experimental/FieldDefaults.html deleted file mode 100644 index 0d4cda9e..00000000 --- a/website2/templates/features/experimental/FieldDefaults.html +++ /dev/null @@ -1,56 +0,0 @@ -<#import "../_features.html" as f> - -<@f.scaffold title="@FieldDefaults" logline="New default field modifiers for the 21st century."> - <@f.history> - <p> - @FieldDefaults was introduced as experimental feature in lombok v0.11.4. - </p> - </@f.history> - - <@f.experimental> - <ul> - <li> - New feature; unsure if this busts enough boilerplate. - </li><li> - Would be nice if you could stick this on the package-info.java package to set the default for all classes in that package. - </li><li> - Part of the work on @Value, which is experimental. - </li> - </ul> - Current status: <em>positive</em> - Currently we feel this feature may move out of experimental status with no or minor changes soon. - </@f.experimental> - - <@f.overview> - <p> - The <code>@FieldDefaults</code> annotation can add an access modifier (<code>public</code>, <code>private</code>, or <code>protected</code>) to each field in the annotated class or enum. It can also add <code>final</code> to each field in the annotated class or enum. - </p><p> - To add <code>final</code> to each (instance) field, use <code>@FieldDefaults(makeFinal=true)</code>. Any non-final field which must remain nonfinal can be annotated with <code>@NonFinal</code> (also in the <code>lombok.experimental</code> package). - </p><p> - To add an access modifier to each (instance) field, use <code>@FieldDefaults(level=AccessLevel.PRIVATE)</code>. Any field that does not already have an access modifier (i.e. any field that looks like package private access) is changed to have the appropriate access modifier. Any package private field which must remain package private can be annotated with <code>@PackagePrivate</code> (also in the <code>lombok.experimental</code> package). - </p> - </@f.overview> - - <@f.snippets name="experimental/FieldDefaults" /> - - <@f.confKeys> - <dt> - <code>lombok.fieldDefaults.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@FieldDefaults</code> as a warning or error if configured. - </dd><dt> - <code>lombok.fieldDefautls.defaultPrivate</code> = [<code>true</code> | <code>false</code>] (default: false) - </dt><dd> - (Since 1.16.8) If set to <code>true</code>, <em>every</em> field in <em>every</em> class or enum anywhere in the sources being compiled will be marked as <code>private</code> unless it has an explicit access modifier or the <code>@PackagePrivate</code> annotation, or an explicit <code>@FieldDefaults</code> annotation is present to override this config key. - </dd><dt> - <code>lombok.fieldDefaults.defaultFinal</code> = [<code>true</code> | <code>false</code>] (default: false) - </dt><dd> - (Since 1.16.8) If set to <code>true</code>, <em>every</em> field in <em>every</em> class or enum anywhere in the sources being compiled will be marked as <code>final</code> unless it has the <code>@NonFinal</code> annotation, or an explicit <code>@FieldDefaults</code> annotation is present to override this config key. - </dd> - </@f.confKeys> - - <@f.smallPrint> - <p> - Like other lombok handlers that touch fields, any field whose name starts with a dollar (<code>$</code>) symbol is skipped entirely. Such a field will not be modified at all. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/experimental/Helper.html b/website2/templates/features/experimental/Helper.html deleted file mode 100644 index 93b6e2b4..00000000 --- a/website2/templates/features/experimental/Helper.html +++ /dev/null @@ -1,52 +0,0 @@ -<#import "../_features.html" as f> - -<@f.scaffold title="@Helper" logline="With a little help from my friends... Helper methods for java."> - <@f.history> - <p> - <code>@Helper</code> was introduced as an experimental feature in lombok v1.16.6. - </p> - </@f.history> - - <@f.experimental> - <ul> - <li> - Lambdas with general function types offer an alternative strategy. - </li><li> - Perhaps a way to make helper methods with less boilerplate is possible, making this feature obsolete. - </li> - </ul> - Current status: <em>unknown</em> - We don't have enough experience with this feature to make predictions on its future. - </@f.experimental> - - <@f.overview> - <p> - This annotation lets you put methods in methods. You might not know this, but you can declare classes inside methods, and the methods in this class can access any (effectively) final local variable or parameter defined and set before the declaration. Unfortunately, to actually call any methods you'd have to make an instance of this method local class first, but that's where <code>@Helper</code> comes in and helps you out! Annotate a method local class with <code>@Helper</code> and it's as if all the methods in that helper class are methods that you can call directly, just as if java had allowed methods to exist inside methods. - </p><p> - Normally you'd have to declare an instance of your helper, for example: <code>HelperClass h = new HelperClass();</code> directly after declaring your helper class, and then call methods in your helper class with <code>h.helperMethod();</code>. With <code>@Helper</code>, both of these things are no longer needed: You do not need to waste a line of code declaring an instance of the helper, and you don't need to prefix all your calls to helper methods with <code>nameOfHelperInstance.</code> - </p> - </@f.overview> - - <@f.snippets name="experimental/Helper" /> - - <@f.confKeys> - <dt> - <code>lombok.helper.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@Helper</code> as a warning or error if configured. - </dd> - </@f.confKeys> - - <@f.smallPrint> - <p> - <code>@Helper</code> requires that the helper class has a no-args constructor. A compiler error will be generated if this is not the case. - </p><p> - Currently, the instance of your helper that's made under the hood is called <code>$Foo</code>, where <code>Foo</code> is the name of your helper. We might change this in the future; please don't rely on this variable existing. We might even replace this later with a sibling method instead. - </p><p> - Please don't rely on <code>this</code> making any sense in the helper method code. You can refer to the real 'this' by using the syntax <code>NameOfMyClass.this</code>. - </p><p> - <em>ANY</em> unqualified method call in code that exists <em>below</em> the declaration of the helper method with the same name as any method in the helper is assumed to be a call to the helper. If the arguments don't end up being compatible, you get a compiler error. - </p><p> - Unless you're using JDK8 or higher (which introduced the concept of 'effectively final'), you'll have to declare local variables and parameters as <code>final</code> if you wish to refer to them in your method local class. This is a java limitation, not something specific to lombok's <code>@Helper</code>. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/experimental/UtilityClass.html b/website2/templates/features/experimental/UtilityClass.html deleted file mode 100644 index 4cee3657..00000000 --- a/website2/templates/features/experimental/UtilityClass.html +++ /dev/null @@ -1,44 +0,0 @@ -<#import "../_features.html" as f> - -<@f.scaffold title="@UtilityClass" logline="Utility, metility, wetility! Utility classes for the masses."> - <@f.history> - <p> - <code>@UtilityClass</code> was introduced as an experimental feature in lombok v1.16.2. - </p> - </@f.history> - - <@f.experimental> - <ul> - <li> - Some debate as to whether its common enough to count as boilerplate. - </li> - </ul> - Current status: <em>positive</em> - Currently we feel this feature may move out of experimental status with no or minor changes soon. - </@f.experimental> - - <@f.overview> - <p> - A utility class is a class that is just a namespace for functions. No instances of it can exist, and all its members are static. For example, <code>java.lang.Math</code> and <code>java.util.Collections</code> are well known utility classes. This annotation automatically turns the annotated class into one. - </p><p> - A utility class cannot be instantiated. By marking your class with <code>@UtilityClass</code>, lombok will automatically generate a private constructor that throws an exception, flags as error any explicit constructors you add, and marks the class <code>final</code>. If the class is an inner class, the class is also marked <code>static</code>. - </p><p> - <em>All</em> members of a utility class are automatically marked as <code>static</code>. Even fields and inner classes. - </p> - </@f.overview> - - <@f.snippets name="experimental/UtilityClass" /> - - <@f.confKeys> - <dt> - <code>lombok.utilityClass.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@UtilityClass</code> as a warning or error if configured. - </dd> - </@f.confKeys> - - <@f.smallPrint> - <p> - There isn't currently any way to create non-static members, or to define your own constructor. If you want to instantiate the utility class, even only as an internal implementation detail, <code>@UtilityClass</code> cannot be used. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/experimental/Wither.html b/website2/templates/features/experimental/Wither.html deleted file mode 100644 index 9642458b..00000000 --- a/website2/templates/features/experimental/Wither.html +++ /dev/null @@ -1,66 +0,0 @@ -<#import "../_features.html" as f> - -<@f.scaffold title="@Wither" logline="Immutable 'setters' - methods that create a clone but with one changed field."> - <@f.history> - <p> - @Wither was introduced as experimental feature in lombok v0.11.4. - </p> - </@f.history> - - <@f.experimental> - <ul> - <li> - Still not sure that <code>@Wither</code> is an appropriate name for this feature. - </li><li> - Should there be an option to supply a way of cloning the input somehow? - </li><li> - Should the way that the clone is created by configurable? - </li><li> - Should we replace @Wither entirely with a builder class? - </li> - </ul> - Current status: <em>neutral</em> - More feedback requires on the items in the above list before promotion to the main package is warranted. - </@f.experimental> - - <@f.overview> - <p> - The next best alternative to a setter for an immutable property is to construct a clone of the object, but with a new value for this one field. A method to generate this clone is precisely what <code>@Wither</code> generates: a <code>withFieldName(newValue)</code> method which produces a clone except for the new value for the associated field. - </p><p> - For example, if you create <code>public class Point { private final int x, y; }</code>, setters make no sense because the fields are final. <code>@Wither</code> can generate a <code>withX(int newXValue)</code> method for you which will return a new point with the supplied value for <code>x</code> and the same value for <code>y</code>. - </p><p> - Like <a href="/features/GetterSetter"><code>@Setter</code></a>, you can specify an access level in case you want the generated wither to be something other than <code>public</code>:<br /> <code>@Wither(level = AccessLevel.PROTECTED)</code>. Also like <a href="/features/GetterSetter"><code>@Setter</code></a>, you can also put a <code>@Wither</code> annotation on a type, which means a 'wither' is generated for each field (even non-final fields). - </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 wither 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 withers. Normally, all text is copied, and <code>@param</code> is <em>moved</em> to the wither, whilst <code>@return</code> lines are stripped from the wither's javadoc. Moved means: Deleted from the field's javadoc. It is also possible to define unique text for the wither's javadoc. To do that, you create a 'section' named <code>WITHER</code>. A section is a line in your javadoc containing 2 or more dashes, then the text 'WITHER', followed by 2 or more dashes, and nothing else on the line. If you use sections, <code>@return</code> and <code>@param</code> stripping / copying for that section is no longer done (move the <code>@param</code> line into the section). - </p> - </@f.overview> - - <@f.snippets name="experimental/Wither" /> - - <@f.confKeys> - <dt> - <code>lombok.wither.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@Wither</code> as a warning or error if configured. - </dd> - </@f.confKeys> - - <@f.smallPrint> - <p> - Withers cannot be generated for static fields because that makes no sense. - </p><p> - Withers can be generated for abstract classes, but this generates an abstract method with the appropriate signature. - </p><p> - When applying <code>@Wither</code> to a type, static fields and fields whose name start with a $ are skipped. - </p><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, <code>with</code> 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>withX(int x)</code> will not be generated if there's already a method <code>withX(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. - </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 wither name. - </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 wither. Also, these annotations (as well as any annotation named <code>@Nullable</code> or <code>@CheckForNull</code>) are copied to wither parameter. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/experimental/index.html b/website2/templates/features/experimental/index.html deleted file mode 100644 index 65cefd4c..00000000 --- a/website2/templates/features/experimental/index.html +++ /dev/null @@ -1,85 +0,0 @@ -<#import "../../_scaffold.html" as main> -<#import "../_features.html" as f> - -<@main.scaffold> - <div class="page-header top5"> - <div class="row text-center"> - <h1>Lombok experimental features</h1> - </div> - <div class="row"> - <p> - Experimental features are available in your normal lombok installation, but are not as robustly supported as lombok's main features. In particular, experimental features: - <ul> - <li> - Are not tested as well as the core features. - </li><li> - Do not get bugs fixed as quickly as core features. - </li><li> - May have APIs that will change, possibly drastically if we find a different, better way to solve the same problem. - </li><li> - May disappear entirely if the feature is too difficult to support or doesn't bust enough boilerplate. - </li> - </ul> - </p><p> - Features that receive positive community feedback and which seem to produce clean, flexible code will eventually become accepted as a core feature and move out of the experimental package. - </p> - </div> - <div class="row"> - <@main.feature title="var" href="var"> - Modifiable local variables with a type inferred by assigning value. - </@main.feature> - - <@main.feature title="@Accessors" href="Accessors"> - A more fluent API for getters and setters. - </@main.feature> - - <@main.feature title="@ExtensionMethod" href="ExtensionMethod"> - Annoying API? Fix it yourself: Add new methods to existing types! - </@main.feature> - - <@main.feature title="@FieldDefaults" href="FieldDefaults"> - New default field modifiers for the 21st century. - </@main.feature> - - <@main.feature title="@Delegate" href="Delegate"> - Don't lose your composition. - </@main.feature> - - <@main.feature title="@Wither" href="Wither"> - Immutable 'setters' - methods that create a clone but with one changed field. - </@main.feature> - - <@main.feature title="onMethod= / onConstructor= / onParam=" href="onX"> - Sup dawg, we heard you like annotations, so we put annotations in your annotations so you can annotate while you're annotating. - </@main.feature> - - <@main.feature title="@UtilityClass" href="UtilityClass"> - Utility, metility, wetility! Utility classes for the masses. - </@main.feature> - - <@main.feature title="@Helper" href="Helper"> - With a little help from my friends... Helper methods for java. - </@main.feature> - </div> - - <@f.confKeys> - <dt> - <code>lombok.experimental.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of any of the features listed here as a warning or error if configured. - </dd> - </@f.confKeys> - - <div class="row"> - <h3 class="text-center">Putting the "Ex" in "Experimental": promoted or deleted experimental features.</h3> - <div class="row"> - <@main.feature title="@Value: promoted" href="../Value"> - <code>@Value</code> has proven its value and has been moved to the main package. - </@main.feature> - <@main.feature title="@Builder: promoted" href="../Builder"> - <code>@Builder</code> is a solid base to build APIs on, and has been moved to the main package. - </@main.feature> - </div> - </div> - </div> -</@main.scaffold> diff --git a/website2/templates/features/experimental/onX.html b/website2/templates/features/experimental/onX.html deleted file mode 100644 index fd2e7b58..00000000 --- a/website2/templates/features/experimental/onX.html +++ /dev/null @@ -1,62 +0,0 @@ -<#import "../_features.html" as f> - -<@f.scaffold title="onX" logline="Sup dawg, we heard you like annotations, so we put annotations in your annotations so you can annotate while you're annotating."> - <@f.history> - <p> - onX was introduced as experimental feature in lombok v0.11.8. - </p> - </@f.history> - - <@f.experimental> - <ul> - <li> - Ugly syntax. The syntax of this feature is not optimal, but it is the least convoluted syntax that could possibly work (for now!) - </li><li> - Possibly java 9 will offer (much) better ways of supporting this feature. - </li><li> - Uncertainty: Future versions of javac may break this feature, and we may not be able to restore it. - </li> - </ul> - Current status: <em>uncertain</em> - Currently we feel this feature cannot move out of experimental status. - </@f.experimental> - - <@f.overview> - <p> - <strong>This feature is considered 'workaround status' - it exists in order to allow users of lombok that cannot work without this feature to have access to it anyway. If we find a better way to implement this feature, or some future java version introduces an alternative strategy, this feature can disappear without a reasonable deprecation period. Also, this feature may not work in future versions of javac. Use at your own discretion.</strong> - </p><p> - Most annotations that make lombok generate methods or constructors can be configured to also make lombok put custom annotations on elements in the generated code. - </p><p> - <code>@Getter</code>, <code>@Setter</code>, and <code>@Wither</code> support the <code>onMethod</code> option, which will put the listed annotations on the generated method. - </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>@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 and depends on the javac you are using.<br /> - On javac7, 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.<br /> - On javac8 and up, you add an underscore after <code>onMethod</code>, <code>onParam</code>, or <code>onConstructor</code>. - </p> - </@f.overview> - - <@f.snippets name="experimental/onX" /> - - <@f.confKeys> - <dt> - <code>lombok.onX.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>onX</code> as a warning or error if configured. - </dd> - </@f.confKeys> - - <@f.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> (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> - 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. - </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> - The <code>onX</code> parameter is not legal on any type-wide variant. For example, a <code>@Getter</code> annotation on a class does not support <code>onMethod</code>. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/experimental/var.html b/website2/templates/features/experimental/var.html deleted file mode 100644 index fa35ac5e..00000000 --- a/website2/templates/features/experimental/var.html +++ /dev/null @@ -1,37 +0,0 @@ -<#import "../_features.html" as f> - -<@f.scaffold title="var" logline="Modifiable local variables with a type inferred by assigning value."> - <@f.history> - <p> - <code>var</code> was introduced in lombok 1.16.12 as experimental feature. - </p> - </@f.history> - - <@f.experimental> - <ul> - <li> - This feature is very controversial. - </li><li> - There is <a href="http://openjdk.java.net/jeps/286">JEP 286</a> that should make <code>var</code> obsolete. - </li> - </ul> - Current status: <em>uncertain</em> – Currently we feel this feature cannot move out of experimental status. - </@f.experimental> - - <@f.overview> - <p> - <code>var</code> works exactly like <a href="/features/val"><code>val</code></a>, except the local variable is <em>not</em> marked as <code>final</code>. - </p><p> - The type is still entirely derived from the mandatory initializer expression, and any further assignments, while now legal (because the variable is no longer <code>final</code>), aren't looked at to determine the appropriate type.<br /> - For example, <code>var x = "Hello"; x = Color.RED;</code> does <em>not</em> work; the type of x will be inferred to be <code>java.lang.String</code> and thus, the <code>x = Color.RED</code> assignment will fail. If the type of <code>x</code> was inferred to be <code>java.lang.Object</code> this code would have compiled, but that's not how<code>var</code> works. - </p> - </@f.overview> - - <@f.confKeys> - <dt> - <code>lombok.var.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>var</code> as a warning or error if configured. - </dd> - </@f.confKeys> -</@f.scaffold> diff --git a/website2/templates/features/index.html b/website2/templates/features/index.html deleted file mode 100644 index da3db634..00000000 --- a/website2/templates/features/index.html +++ /dev/null @@ -1,87 +0,0 @@ -<#import "../_scaffold.html" as main> - -<@main.scaffold> - <div class="page-header top5"> - <div class="row text-center"> - <h1>Lombok features.</h1> - </div> - <div class="row"> - <@main.feature title="val" href="val"> - Finally! Hassle-free final local variables. - </@main.feature> - - <@main.feature title="@NonNull" href="NonNull"> - or: How I learned to stop worrying and love the NullPointerException. - </@main.feature> - - <@main.feature title="@Cleanup" href="Cleanup"> - Automatic resource management: Call your <code>close()</code> methods safely with no hassle. - </@main.feature> - - <@main.feature title="@Getter/@Setter" href="GetterSetter"> - Never write <code>public int getFoo() {return foo;}</code> again. - </@main.feature> - - <@main.feature title="@ToString" href="ToString"> - No need to start a debugger to see your fields: Just let lombok generate a <code>toString</code> for - you! - </@main.feature> - - <@main.feature title="@EqualsAndHashCode" href="EqualsAndHashCode"> - Equality made easy: Generates <code>hashCode</code> and <code>equals</code> implementations from the - fields of your object.. - </@main.feature> - - <@main.feature title="@NoArgsConstructor, @RequiredArgsConstructor and @AllArgsConstructor" href="constructor"> - Constructors made to order: Generates constructors that take no arguments, one argument per final / - non-nullfield, or one argument for every field. - </@main.feature> - - <@main.feature title="@Data" href="Data"> - All together now: A shortcut for <code>@ToString</code>, <code>@EqualsAndHashCode</code>, - <code>@Getter</code> on all fields, and <code>@Setter</code> on all non-final fields, and - <code>@RequiredArgsConstructor</code>! - </@main.feature> - - <@main.feature title="@Value" href="Value"> - Immutable classes made very easy. - </@main.feature> - - <@main.feature title="@Builder" href="Builder"> - ... and Bob's your uncle: No-hassle fancy-pants APIs for object creation! - </@main.feature> - - <@main.feature title="@SneakyThrows" href="SneakyThrows"> - To boldly throw checked exceptions where no one has thrown them before! - </@main.feature> - - <@main.feature title="@Synchronized" href="Synchronized"> - <code>synchronized</code> done right: Don't expose your locks. - </@main.feature> - - <@main.feature title="@Getter(lazy=true)" href="GetterLazy"> - Laziness is a virtue! - </@main.feature> - - <@main.feature title="@Log" href="log"> - Captain's Log, stardate 24435.7: "What was that line again?" - </@main.feature> - </div> - - <div class="row"> - <h1>Configuration system</h1> - - <div class="text-center"> - Lombok, made to order: <a href="configuration">Configure lombok features</a> in one place for your entire project or even your workspace. - </div> - </div> - - <div class="row"> - <h1 class="text-center">Running delombok</h1> - - <div> - Delombok copies your source files to another directory, replacing all lombok annotations with their desugared form. So, it'll turn <code>@Getter</code> back into the actual getter. It then removes the annotation. This is useful for all sorts of reasons; you can check out what's happening under the hood, if the unthinkable happens and you want to stop using lombok, you can easily remove all traces of it in your source, and you can use delombok to preprocess your source files for source-level tools such as javadoc and GWT. More information about how to run delombok, including instructions for build tools can be found at the <a href="delombok">delombok page</a>. - </div> - </div> - </div> -</@main.scaffold> diff --git a/website2/templates/features/log.html b/website2/templates/features/log.html deleted file mode 100644 index 2854e896..00000000 --- a/website2/templates/features/log.html +++ /dev/null @@ -1,106 +0,0 @@ -<#import "_features.html" as f> - -<@f.scaffold title="@Log (and friends)" logline="Captain's Log, stardate 24435.7: "What was that line again?""> - <@f.history> - <p> - The various <code>@Log</code> variants were added in lombok v0.10. - <em>NEW in lombok 0.10: </em>You can annotate any class with a log annotation to let lombok generate a logger field.<br/> - The logger is named <code>log</code> and the field's type depends on which logger you have selected. - </p> - </@f.history> - - <@f.overview> - <p> - You put the variant of <code>@Log</code> on your class (whichever one applies to the logging system you use); you then have a static final <code>log</code> field, initialized to the name of your class, which you can then use to write log statements. - </p><p> - There are several choices available:<br /> - <dl> - <dt> - <code>@CommonsLog</code> - </dt><dd> - Creates <code><span class="keyword">private static final </span><a href="https://commons.apache.org/logging/apidocs/org/apache/commons/logging/Log.html">org.apache.commons.logging.Log</a> <span class="staticfield">log</span> = <a href="https://commons.apache.org/logging/apidocs/org/apache/commons/logging/LogFactory.html#getLog(java.lang.Class)">org.apache.commons.logging.LogFactory.getLog</a>(LogExample.<span class="keyword">class</span>);</code> - </dd><dt> - <code>@JBossLog</code> - </dt><dd> - Creates <code><span class="keyword">private static final </span><a href="http://docs.jboss.org/jbosslogging/latest/org/jboss/logging/Logger.html">org.jboss.logging.Logger</a> <span class="staticfield">log</span> = <a href="http://docs.jboss.org/jbosslogging/latest/org/jboss/logging/Logger.html#getLogger(java.lang.Class)">org.jboss.logging.Logger.getLogger</a>(LogExample.<span class="keyword">class</span>);</code> - </dd><dt> - <code>@Log</code> - </dt><dd> - Creates <code><span class="keyword">private static final </span><a href="http://download.oracle.com/javase/6/docs/api/java/util/logging/Logger.html">java.util.logging.Logger</a> <span class="staticfield">log</span> = <a href="http://download.oracle.com/javase/6/docs/api/java/util/logging/Logger.html#getLogger(java.lang.String)">java.util.logging.Logger.getLogger</a>(LogExample.<span class="keyword">class</span>.getName());</code> - </dd><dt> - <code>@Log4j</code> - </dt><dd> - Creates <code><span class="keyword">private static final </span><a href="https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Logger.html">org.apache.log4j.Logger</a> <span class="staticfield">log</span> = <a href="https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Logger.html#getLogger(java.lang.Class)">org.apache.log4j.Logger.getLogger</a>(LogExample.<span class="keyword">class</span>);</code> - </dd><dt> - <code>@Log4j2</code> - </dt><dd> - Creates <code><span class="keyword">private static final </span><a href="https://logging.apache.org/log4j/2.0/log4j-api/apidocs/org/apache/logging/log4j/Logger.html">org.apache.logging.log4j.Logger</a> <span class="staticfield">log</span> = <a href="https://logging.apache.org/log4j/2.0/log4j-api/apidocs/org/apache/logging/log4j/LogManager.html#getLogger(java.lang.Class)">org.apache.logging.log4j.LogManager.getLogger</a>(LogExample.<span class="keyword">class</span>);</code> - </dd><dt> - <code>@Slf4j</code> - </dt><dd> - Creates <code><span class="keyword">private static final </span><a href="http://www.slf4j.org/api/org/slf4j/Logger.html">org.slf4j.Logger</a> <span class="staticfield">log</span> = <a href="http://www.slf4j.org/apidocs/org/slf4j/LoggerFactory.html#getLogger(java.lang.Class)">org.slf4j.LoggerFactory.getLogger</a>(LogExample.<span class="keyword">class</span>);</code> - </dd><dt> - <code>@XSlf4j</code> - </dt><dd> - Creates <code><span class="keyword">private static final </span><a href="http://www.slf4j.org/api/org/slf4j/ext/XLogger.html">org.slf4j.ext.XLogger</a> <span class="staticfield">log</span> = <a href="http://www.slf4j.org/apidocs/org/slf4j/ext/XLoggerFactory.html#getXLogger(java.lang.Class)">org.slf4j.ext.XLoggerFactory.getXLogger</a>(LogExample.<span class="keyword">class</span>);</code> - </dd> - </dl> - </p><p> - By default, the topic (or name) of the logger will be the class name of the class annotated with the <code>@Log</code> annotation. This can be customised by specifying the <code>topic</code> parameter. For example: <code>@XSlf4j(topic="reporting")</code>. - </p> - </@f.overview> - - <@f.snippets name="Log" /> - - <@f.confKeys> - <dt> - <code>lombok.log.fieldName</code> = <em>an identifier</em> (default: <code>log</code>). - </dt><dd> - The generated logger fieldname is by default '<code>log</code>', but you can change it to a different name with this setting. - </dd><dt> - <code>lombok.log.fieldIsStatic</code> = [<code>true</code> | <code>false</code>] (default: true) - </dt><dd> - Normally the generated logger is a <code>static</code> field. By setting this key to <code>false</code>, the generated field will be an instance field instead. - </dd><dt> - <code>lombok.log.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of any of the various log annotations as a warning or error if configured. - </dd><dt> - <code>lombok.log.apacheCommons.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@lombok.extern.apachecommons.CommonsLog</code> as a warning or error if configured. - </dd><dt> - <code>lombok.log.javaUtilLogging.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@lombok.extern.java.Log</code> as a warning or error if configured. - </dd><dt> - <code>lombok.log.jbosslog.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@lombok.extern.jbosslog.JBossLog</code> as a warning or error if configured. - </dd><dt> - <code>lombok.log.log4j.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@lombok.extern.log4j.Log4j</code> as a warning or error if configured. - </dd><dt> - <code>lombok.log.log4j2.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@lombok.extern.log4j.Log4j2</code> as a warning or error if configured. - </dd><dt> - <code>lombok.log.slf4j.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@lombok.extern.slf4j.Slf4j</code> as a warning or error if configured. - </dd><dt> - <code>lombok.log.xslf4j.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>@lombok.extern.slf4j.XSlf4j</code> as a warning or error if configured. - </dd> - </@f.confKeys> - - <@f.smallPrint> - <p> - If a field called <code>log</code> already exists, a warning will be emitted and no code will be generated. - </p><p> - A future feature of lombok's diverse log annotations 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 <code>if</code> 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 <em>NOT</em> put any side-effects in the expression that you log. - </p> - </@f.smallPrint> -</@f.scaffold> diff --git a/website2/templates/features/val.html b/website2/templates/features/val.html deleted file mode 100644 index 32a8ffdf..00000000 --- a/website2/templates/features/val.html +++ /dev/null @@ -1,36 +0,0 @@ -<#import "_features.html" as f> - -<@f.scaffold title="val" logline="Finally! Hassle-free final local variables."> - <@f.history> - <p> - <code>val</code> was introduced in lombok 0.10. - </p> - </@f.history> - <@f.overview> - <p> - You can use <code>val</code> 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. - </p><p> - <code>val</code> is actually a 'type' of sorts, and exists as a real class in the <code>lombok</code> package. You must import it for val to work (or use <code>lombok.val</code> as the type). The existence of this type on a local variable declaration triggers both the adding of the <code>final</code> keyword as well as copying the type of the initializing expression which overwrites the 'fake' <code>val</code> type. - </p><p> - <em>WARNING: This feature does not currently work in NetBeans.</em> - </p> - </@f.overview> - - <@f.snippets name="val" /> - - <@f.confKeys> - <dt> - <code>lombok.val.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set) - </dt><dd> - Lombok will flag any usage of <code>val</code> as a warning or error if configured. - </dd> - </@f.confKeys> - - <@f.smallPrint> - <p> - For compound types, the most common superclass is inferred, not any shared interfaces. For example, <code>bool ? new HashSet() : new ArrayList()</code> is an expression with a compound type: The result is both <code>AbstractCollection</code> as well as <code>Serializable</code>. The type inferred will be <code>AbstractCollection</code>, as that is a class, whereas <code>Serializable</code> is an interface. - </p><p> - In ambiguous cases, such as when the initializer expression is <code>null</code>, <code>java.lang.Object</code> is inferred. - </p> - </@f.smallPrint> -</@f.scaffold> |