From 8b7a7cbc813653a3248d6cf3a7779e220957bc85 Mon Sep 17 00:00:00 2001
From: Reinier Zwitserloot
-
- The
- By default, lombok follows the bean specification for getters and setters: The getter for a field named
- Some programmers like to use a prefix for their fields, i.e. they write
-
- The
- The nearest
- 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.
-
-
- Any field or no-argument method can be annotated with
- Lombok delegates all
- You can pass any number of classes into the
- All public non-
- 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
- When passing classes to the annotation's
- When passing classes to the annotation, these classes do not need to be supertypes of the field. See the example.
-
-
-
-
- You can make a class containing a bunch of
- For example, if you create
- All methods that are
- You can pass any number of classes to the
- 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: @Accessors
was introduced as experimental feature in lombok v0.11.0.
-
-
- Current status: positive - Currently we feel this feature may move out of experimental status with no or minor changes soon.
- @f.experimental>
-
- <@f.overview>
- @Accessors
annotation is used to configure how lombok generates and looks for getters and setters.
- pepper
is getPepper
for example. However, some might like to break with the bean specification in order to end up with nicer looking APIs. @Accessors
lets you do this.
- fPepper
instead of pepper
. We strongly 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 @Accessors
as well.
- @Accessors
therefore has 3 options:
-
-
- fluent
– A boolean. If true, the getter for pepper
is just pepper()
, and the setter is pepper(T newValue)
. Furthermore, unless specified, chain
defaults to true.
- Default: false.
- chain
– A boolean. If true, generated setters return this
instead of void
.
- Default: false, unless fluent=true
, then Default: true.
- prefix
– 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. pepper
is not a match even to prefix p
, but pEpper
would be (and would mean the base name of this field is epper
).
- @Accessors
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 @Accessors
annotation on a field is present, any @Accessors
annotation also present on that field's type is ignored.
- lombok.accessors.chain
= [true
| false
] (default: false)
- true
, any class that either doesn't have an @Accessors
annotation, or it does, but that annotation does not have an explicit value for the chain
parameter, will act as if @Accessors(chain = true)
is present.
- lombok.accessors.fluent
= [true
| false
] (default: false)
- true
, any class that either doesn't have an @Accessors
annotation, or it does, but that annotation does not have an explicit value for the fluent
parameter, will act as if @Accessors(fluent = true)
is present.
- lombok.accessors.prefix
+= a field prefix (default: empty list)
- +=
operator. Inherited prefixes from parent config files can be removed with the -=
operator. Any class that either doesn't have an @Accessors
annotation, or it does, but that annotation does not have an explicit value for the prefix
parameter, will act as if @Accessors(prefix = {prefixes listed in configuration})
is present.
- lombok.accessors.flagUsage
= [warning
| error
] (default: not set)
- @Accessors
as a warning or error if configured.
- @Accessors
annotation is also used for the various methods in lombok that look for getters, such as @EqualsAndHashCode
.
- @Delegate
was introduced as feature in lombok v0.10 (the experimental package did not exist yet).
- It was moved to the experimental package in lombok v1.14; the old version from the main lombok package is now deprecated.
-
-
- Current status: negative - 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>
- @Delegate
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.
- @Delegate
to let lombok generate delegate methods that forward the call to this field (or the result of invoking this method).
- public
methods of the field's type (or method's return type), as well as those of its supertypes except for all methods declared in java.lang.Object
.
- @Delegate
annotation's types
parameter. If you do that, then lombok will delegate all public
methods in those types (and their supertypes, except java.lang.Object
) instead of looking at the field/method's type.
- Object
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 @Delegate(excludes=SomeType.class)
parameter to exclude all public methods in the excluded type(s), and their supertypes.
- @Delegate(types=PrivateInnerInterfaceWithIncludesList.class, excludes=SameForExcludes.class)
.
- lombok.delegate.flagUsage
= [warning
| error
] (default: not set)
- @Delegate
as a warning or error if configured.
- types
or excludes
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.
- @Delegate
cannot be used on static fields or methods.
- @Delegate
cannot be used when the calculated type(s) to delegate / exclude themselves contain @Delegate
annotations; in other words, @Delegate
will error if you attempt to use it recursively.
- @ExtensionMethod
was introduced as experimental feature in lombok v0.11.2.
-
-
- Current status: hold - 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>
- public
, static
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 @ExtensionMethod
feature.
- public static String toTitleCase(String in) { ... }
, you can use the @ExtensionMethod
feature to make it look like the java.lang.String
class has a method named toTitleCase
, which has no arguments. The first argument of the static method fills the role of this
in instance methods.
- public
, static
, 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: foo.toTitleCase()
is replaced with ClassContainingYourExtensionMethod.toTitleCase(foo);
. Note that it is actually not an instant NullPointerException
if foo
is null - it is passed like any other parameter.
- @ExtensionMethod
annotation; they will all be searched for extension methods. These extension methods apply for any code that is in the annotated class.
-
- public class ObjectExtensions {
- public static <T> or(T object, T ifNull) {
- return object != null ? object : ifNull;
- }
-}
- With the above class, if you add @ExtensionMethod(ObjectExtensions.class)
to your class definition, you can write:
- String x = null;
-System.out.println(x.or("Hello, World!"));
- The above code will not fail with a NullPointerException
; it will actually output Hello, World!
-
lombok.extensionMethod.flagUsage
= [warning
| error
] (default: not set)
- @ExtensionMethod
as a warning or error if configured.
- - 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. -
- Generics is fully applied to figure out extension methods. i.e. if the first parameter of your extension method is List<? extends String>
, then any expression that is compatible with that will have your extension method, but other kinds of lists won't. So, a List<Object>
won't get it, but a List<String>
will.
-
- @FieldDefaults was introduced as experimental feature in lombok v0.11.4. -
- @f.history> - - <@f.experimental> -
- The @FieldDefaults
annotation can add an access modifier (public
, private
, or protected
) to each field in the annotated class or enum. It can also add final
to each field in the annotated class or enum.
-
- To add final
to each (instance) field, use @FieldDefaults(makeFinal=true)
. Any non-final field which must remain nonfinal can be annotated with @NonFinal
(also in the lombok.experimental
package).
-
- To add an access modifier to each (instance) field, use @FieldDefaults(level=AccessLevel.PRIVATE)
. 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 @PackagePrivate
(also in the lombok.experimental
package).
-
lombok.fieldDefaults.flagUsage
= [warning
| error
] (default: not set)
- @FieldDefaults
as a warning or error if configured.
- lombok.fieldDefautls.defaultPrivate
= [true
| false
] (default: false)
- true
, every field in every class or enum anywhere in the sources being compiled will be marked as private
unless it has an explicit access modifier or the @PackagePrivate
annotation, or an explicit @FieldDefaults
annotation is present to override this config key.
- lombok.fieldDefaults.defaultFinal
= [true
| false
] (default: false)
- true
, every field in every class or enum anywhere in the sources being compiled will be marked as final
unless it has the @NonFinal
annotation, or an explicit @FieldDefaults
annotation is present to override this config key.
-
- Like other lombok handlers that touch fields, any field whose name starts with a dollar ($
) symbol is skipped entirely. Such a field will not be modified at all.
-
- @Helper
was introduced as an experimental feature in lombok v1.16.6.
-
- 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 @Helper
comes in and helps you out! Annotate a method local class with @Helper
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.
-
- Normally you'd have to declare an instance of your helper, for example: HelperClass h = new HelperClass();
directly after declaring your helper class, and then call methods in your helper class with h.helperMethod();
. With @Helper
, 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 nameOfHelperInstance.
-
lombok.helper.flagUsage
= [warning
| error
] (default: not set)
- @Helper
as a warning or error if configured.
-
- @Helper
requires that the helper class has a no-args constructor. A compiler error will be generated if this is not the case.
-
- Currently, the instance of your helper that's made under the hood is called $Foo
, where Foo
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.
-
- Please don't rely on this
making any sense in the helper method code. You can refer to the real 'this' by using the syntax NameOfMyClass.this
.
-
- ANY unqualified method call in code that exists below 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. -
- Unless you're using JDK8 or higher (which introduced the concept of 'effectively final'), you'll have to declare local variables and parameters as final
if you wish to refer to them in your method local class. This is a java limitation, not something specific to lombok's @Helper
.
-
- @UtilityClass
was introduced as an experimental feature in lombok v1.16.2.
-
- 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, java.lang.Math
and java.util.Collections
are well known utility classes. This annotation automatically turns the annotated class into one.
-
- A utility class cannot be instantiated. By marking your class with @UtilityClass
, lombok will automatically generate a private constructor that throws an exception, flags as error any explicit constructors you add, and marks the class final
. If the class is an inner class, the class is also marked static
.
-
- All members of a utility class are automatically marked as static
. Even fields and inner classes.
-
lombok.utilityClass.flagUsage
= [warning
| error
] (default: not set)
- @UtilityClass
as a warning or error if configured.
-
- 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, @UtilityClass
cannot be used.
-
- @Wither was introduced as experimental feature in lombok v0.11.4. -
- @f.history> - - <@f.experimental> -@Wither
is an appropriate name for this feature.
-
- 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 @Wither
generates: a withFieldName(newValue)
method which produces a clone except for the new value for the associated field.
-
- For example, if you create public class Point { private final int x, y; }
, setters make no sense because the fields are final. @Wither
can generate a withX(int newXValue)
method for you which will return a new point with the supplied value for x
and the same value for y
.
-
- Like @Setter
, you can specify an access level in case you want the generated wither to be something other than public
:
@Wither(level = AccessLevel.PROTECTED)
. Also like @Setter
, you can also put a @Wither
annotation on a type, which means a 'wither' is generated for each field (even non-final fields).
-
- To put annotations on the generated method, you can use onMethod=@__({@AnnotationsHere})
; to put annotations on the only parameter of a generated wither method, you can use onParam=@__({@AnnotationsHere})
. Be careful though! This is an experimental feature. For more details see the documentation on the onX feature.
-
- NEW in lombok v1.12.0: javadoc on the field will now be copied to generated withers. Normally, all text is copied, and @param
is moved to the wither, whilst @return
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 WITHER
. 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, @return
and @param
stripping / copying for that section is no longer done (move the @param
line into the section).
-
lombok.wither.flagUsage
= [warning
| error
] (default: not set)
- @Wither
as a warning or error if configured.
- - Withers cannot be generated for static fields because that makes no sense. -
- Withers can be generated for abstract classes, but this generates an abstract method with the appropriate signature. -
- When applying @Wither
to a type, static fields and fields whose name start with a $ are skipped.
-
- 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, with
is prefixed.
-
- No method is generated if any method already exists with the same name (case insensitive) and same parameter count. For example, withX(int x)
will not be generated if there's already a method withX(String... x)
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.
-
- For boolean
fields that start with is
immediately followed by a title-case letter, nothing is prefixed to generate the wither name.
-
- Any annotations named @NonNull
(case insensitive) on the field are interpreted as: This field must not ever hold null. Therefore, these annotations result in an explicit null check in the generated wither. Also, these annotations (as well as any annotation named @Nullable
or @CheckForNull
) are copied to wither parameter.
-
- Experimental features are available in your normal lombok installation, but are not as robustly supported as lombok's main features. In particular, experimental features: -
- 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. -
-lombok.experimental.flagUsage
= [warning
| error
] (default: not set)
- @Value
has proven its value and has been moved to the main package.
- @main.feature>
- <@main.feature title="@Builder: promoted" href="../Builder">
- @Builder
is a solid base to build APIs on, and has been moved to the main package.
- @main.feature>
- - onX was introduced as experimental feature in lombok v0.11.8. -
- @f.history> - - <@f.experimental> -- 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. -
- 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. -
- @Getter
, @Setter
, and @Wither
support the onMethod
option, which will put the listed annotations on the generated method.
-
- @AllArgsConstructor
, @NoArgsConstructor
, and @RequiredArgsConstructor
support the onConstructor
option which will put the listed annotations on the generated constructor.
-
- @Setter
and @Wither
support onParam
in addition to onMethod
; annotations listed will be put on the only parameter that the generated method has. @EqualsAndHashCode
also supports onParam
; the listed annotation(s) will be placed on the single parameter of the generated equals
method, as well as any generated canEqual
method.
-
- The syntax is a little strange and depends on the javac you are using.
- On javac7, to use any of the 3 onX
features, you must wrap the annotations to be applied to the constructor / method / parameter in @__(@AnnotationGoesHere)
. To apply multiple annotations, use @__({@Annotation1, @Annotation2})
. The annotations can themselves obviously have parameters as well.
- On javac8 and up, you add an underscore after onMethod
, onParam
, or onConstructor
.
-
lombok.onX.flagUsage
= [warning
| error
] (default: not set)
- onX
as a warning or error if configured.
-
- The reason of the weird syntax is to make this feature work in javac 7 compilers; the @__
type is an annotation reference to the annotation type __
(double underscore) which doesn't actually exist; this makes javac 7 delay aborting the compilation process due to an error because it is possible an annotation processor will later create the __
type. Instead, lombok applies the annotations and removes the references so that the error will never actually occur. The point is: The __
type must not exist, otherwise the feature does not work. In the rare case that the __
type does exist (and is imported or in the package), you can simply add more underscores. Technically any non-existent type would work, but to maintain consistency and readability and catch erroneous use, lombok considers it an error if the 'wrapper' annotation is anything but a series of underscores.
-
- In javac8, the above feature should work but due to a bug in javac8 it does not. However, starting in javac8, if the parameter name does not exist in the annotation type, compilation proceeds to a phase where lombok can fix it. -
- To reiterate: This feature can disappear at any time; if you use this feature, be prepared to adjust your code when we find a nicer way of implementing this feature, or, if a future version of javac forces us to remove this feature entirely with no alternative. -
- The onX
parameter is not legal on any type-wide variant. For example, a @Getter
annotation on a class does not support onMethod
.
-
- var
was introduced in lombok 1.16.12 as experimental feature.
-
var
obsolete.
-
- var
works exactly like val
, except the local variable is not marked as final
.
-
- The type is still entirely derived from the mandatory initializer expression, and any further assignments, while now legal (because the variable is no longer final
), aren't looked at to determine the appropriate type.
- For example, var x = "Hello"; x = Color.RED;
does not work; the type of x will be inferred to be java.lang.String
and thus, the x = Color.RED
assignment will fail. If the type of x
was inferred to be java.lang.Object
this code would have compiled, but that's not howvar
works.
-
lombok.var.flagUsage
= [warning
| error
] (default: not set)
- var
as a warning or error if configured.
-