An annotation processor for generating type-safe bean mappers
@TargetPropertyName
can be used to access the target property name to conditional and mapping methods@AnnotateWith
. If a method is annotated with @Deprecated
it is automatically copied into the generated code.nullValueIterableMappingStrategy
and nullValueMapMappingStrategy
(#2953) - The different strategies can be configured using mapstruct.nullValueIterableMappingStrategy
and mapstruct.nullValueMapMappingStrategy
respectivelySubclassMapping
annotated methods (#3119)AdditionalSupportedOptionsProvider
that can be used to defined the supported options for a custom SPI. The additional options cannot start with mapstruct
.@Javadoc
Enum
and Integer
(#2963)Locale
and String
(#3172)java.time.LocalDate
and java.time.LocalDateTime
(#3199)@AnnotateWith(value = Service.class, elements = @AnnotateWith.Element(strings = "cakeMapperV2"))
@ValueMapping
(#3037)CollectionMappingStrategy#TARGET_IMMUTABLE
(#2952)SubclassMapping
(#3202)@InheritConfiguration
for @SubclassMapping
in methods with identical signature (#3125)subclassExhaustiveStrategy
when source is a sealed class and all subtypes are specified (#3054)String
type for @TargetPropertyName
(#2863)@BeforeMapping
with @TargetType
the type being build@AfterMapping
with @TargetType
the type being build@AfterMapping
with @MappingTarget
the type being build@Default
on Java Record's constructor isn't respected (#3231)InjectionStrategy.SETTER
(#3229)BeanMapping#unmappedSourcePolicy
(#3309)Iterable
to Collection
(#3376)@TargetType
on Collection
fails to compile (#2901)@SubclassMapping
(#3174)@BeanMapping(ignoreByDefault = true)
does not work for constructor properties (#3158)@ValueMapping
strips spaces from source (#3153)defaultExpression
does not work when mapping a collection of custom types (#3159)NullPointerException
when ignoring target '.' (#3238) - There is now a compilation error instead of an error in the processorNullValuePropertyMappingStrategy.IGNORE
does not ignore target collection even when source one is null (only when collectionMappingStrategy = CollectionMappingStrategy.TARGET_IMMUTABLE
) (#3104)@SubclassMapping
not working with @Mapping
nested properties and target all (#3126)default
and static
methods in @MapperConfig
(#3296)CollectionMappingStrategy.ADDER_PREFERRED
fails (#3310)@InheritConfiguration
(#3361)In 1.5 we added support for mapping a map to a bean by implicitly mapping all the properties from the target bean by accessing them from the map. However, this lead to some problems in multi mapping methods. Therefore, in this release we tightened up a bit and in multi source mapping methods the Map will not be considered when doing implicit mappings.
e.g.
@Mapper
public interface CarMapper {
// This method is going to implicitly map all the target properties from the map
Target map(Map<String, Object> map);
// This method is not going to use the map for implicit mappings.
// Only the name will be mapped from the map (since it has been defined like that
@Mapping(target = "name", source = "map.name")
Target map(Source source, Map<String, Object> map)
}
@BeanMapping
inheritanceAll, except resultType
and ignoredUnmappedSourceProperties
attributes of @BeanMapping
have been made to consistently be passed down to the generated nested methods. This means that if you were relying on some buggy behavior it might no longer work.
e.g. BeanMapping#ignoreByDefault
was not being passed down properly, i.e. implicit mapping was being done for nested properties. This has been fixed. If you want to implicitly map nested mappings then you'll have to define your own mapper appropriatelly.
@Mapper
interface MyMapper {
@BeanMapping( ignoreByDefault = true )
@Mapping( source = "sub", target = "target" )
Target map( Source source );
}
needs to be replaced with
@Mapper
interface MyMapper {
@BeanMapping( ignoreByDefault = true )
@Mapping( source = "sub", target = "target" )
Target map( Source source );
// this is the mapping `source = "sub"` and `target = "target"`
// redefined to get rid of the `ignoreByDefault=true`, because this property is inherited
SubTarget subSourceToSubTarget( SubSource subSource );
}
After the request from the community we have enabled sponsoring for the project. See #2340 for how you can sponsor us if you want to.
@ApplicationScoped
is missing (#2950)throws
clauses when mapping enum with checked exceptions (#3110)Mapping
annotations for nested objects (worked with 1.5.2) (#3057)BeanMapping#mappingControl
(#3040)<THROW_EXCEPTION>
in the reference guide (#3112)@AfterMapping
does not consider @MappingTarget
properly in 1.5 (#3036)@AfterMapping
is not called (#2955)SubclassMapping
doesn't honour mappingControl
(#3018)BigDecimal
to primitive double
wrong with 1.5.2 (#2913)SubclassMapping
stackoverflow exception (#2825)Optional
wrapping pattern broken in 1.5.2.Final (#2925)@Conditional
and collection (#2937)try-catch
block (#2839)@TargetType
as a parameter for @Condition
causes NPE during compiling (#2882)BeanMapping#ignoreByDefault
(#2929)SubclassExhaustiveStrategy.RUNTIME_EXCEPTION
option does not work if the superclass has a non-empty constructor #2891@Condition
on a presence check for a generic wrapper (#2795)conditionExpression
and expression
are used together (#2794)@BeforeMapping
on a used
mapper (#2807)@BeforeMapping
/ @AfterMapping
methods (#2674)@DecoratedWith
does not work with incremental compilation in Gradle 7.3 (#2682)@InheritInverseConfiguration
with @SubclassMapping
(s) (#2696)qualifiedByName
, uses
and method chaining (#2538) - In 1.4 we strengthened the check for qualified methods and reported an error if there was no applicable qualifier. This strengthening led to 2-step mappings not to work properly when only one of the steps is qualified. With this issue it is now possible to use 2-step mappings with only one of the steps being qualified.javax.annotation.processing.Generated
in modular Java does not seem to work (#2629)@Condition
docs out of sync (#2689)NullValueMappingStrategy
for collections and maps (#2687)@AfterMapping
/ @BeforeMapping
methods (#2719)We'd like to thank all the contributors who worked on this release!
NullValueMappingStrategy
option to map collections/maps, but not beans (#2351)@MappingTarget
) when the source object is null (#1752) - See Behaviour Changes@Mapper
annotation (#2225)CaseEnumTransformationStrategy
(#2525)URL
and String
(#2552)unmappedSourcePolicy
annotation processor argument (#2555)ZonedDateTime
field mapping regression (#2530)unmappedSourcePolicy
and implicit source mapping (#2537)ReverseConversion
should maintain RequiredHelperMethods
(#2544)BeanMapping#ignoreByDefault
interaction with unmappedSourcePolicy
(#2560)Stream
to Array
(#2614)Map
to Bean (#2624)@Condition
not working when the source in the Mapping is the source parameter (#2666)defaultValue
(#2636)Prior to this release update mappings with a return type returned null
when the source parameter was null
. However, this is not what a user expects (see https://github.com/mapstruct/mapstruct/issues/1752).
With this release methods like
Car updateCar(CarDto source, @MappingTarget Car car);
will always return the @MappingTarget
method, irregardless of what the source is.
Map<String, ???>
to Bean (#1075)Iterable<?>
object to an object instead of collection (#607)String
<-> StringBuilder
(#597)UUID
to a String
(#2391)componentModel
in MappingConstants.ComponentModel
(#2255)INSTANCE
(if it exists) in mapper references when using the default component model (#2277)@ObjectFactory
unmappedTargetPolicy
for @BeanMapping
(#2132)java.time.format.DateTimeFormatter
instances final members (#2329)BeanMapping#ignoreUnmappedSourceProperties
were ignored, now there will be a compile error as it is most likely a mistake. To fix the error the unknown properties should be removed from BeanMapping#ignoreUnmappedSourceProperties
defaultExpression
lead to unnecessary null checks and unexpected code (#2023)@ValueMapping
string-to-enum mapping results in no cases in switch (#2350)@InheritInverseConfiguration
(#2356)Enum[]
to String, the mapping processor throws NPE (#2439)@Mapping
(#2368)The introduction of the mapping from Map<String, ???>
to Bean might have lead to some changes in how currently explicitly mapped maps are mapped. Some known changes are: