Quite often there is a need to apply validation to some of the bean's properties based on the state of the other properties of the same bean. Bean Validation allows to do this in several ways:

• usage of @AssertTrue on a getter method with validation logic
• usage of @ScriptAssert on a class level (Hibernate Validator specific)
• usage of custom constraint annotation on a class level

Usage of @AssertTrue on a getter method

Important thing to note here is that the validated getter method LibraryMember#isValidMember() is private. This was done deliberately, as we don't want to expose any unnecessary methods as part of the visible API of the particular bean. Such methods should only be used by the Bean Validation and not called explicitly by the users. To make sure that validation works correctly and more importantly - that such private getter is picked up by the Bean Validation we can run a few tests: We can also check that the constraint is not lost and is "inherited" by the subclasses. For that we can create ExtendedLibraryMember that extends our  LibraryMember with constructors matching the ones from the super class and nothing else.
Such approach is fast and easy to implement. But it also has some downsides as well. First of all, we mix the validation logic with the bean logic, we mix multiple responsibilities in one class. While it might be fine for a few such rules, it gets much messier as more validation rules we have. Also we cannot easily test these validation rules separately.

Usage of @ScriptAssert as a class level constraint

The previous approach had some downsides, maybe this one would be better? Hibernate Validator as a reference implementation of Bean Validation provides additional functionality and constraints. One of such constraints is  @ScriptAssert, which allows to write simple class level constraints using script expressions written in one of the JSR 223 complaint scripting languages. To apply the same validation rule as in the previous case we simply need to add this constraint on a class level as in the following example:

Usage of custom constraint on a class level

For a more detailed instructions on how to create and add custom constraint please see this post Adding custom constraint definitions via the Java service loader.
With the constraint and validator in place we can annotate our class with the new constraint annotation: and run the same set of tests as in other cases. This approach allows us to move the validation logic out of the bean and also gives us more flexibility as we have access to ConstraintValidatorContext, and in case of Hibernate Validator - to HibernateConstraintValidatorInitializationContext initialization context as well. For example we can provide different messages for different types of library members. This can be done with the usage of ConstraintValidatorContext as in the example below, where constraint violation is built manually: This approach is more flexible but it also requires a bit more work and a few more classes to write.

Conclusions

We looked at a few ways on how we can implement validation rules, which require knowledge of the state of multiple properties. Let's point out the advantages and disadvantages of each approach as well as when they should be used.
Using getter and @AssertTrue.
Advantages:

• Probably the fastest and easiest of all the others to achieve the result

Disadvantages:

• Validation logic lives in the bean
• Hard to test separate validation rules, as getters are not publicly available

When to use:

• Can be used when there's a very small amount of such getters and they are relatively simple

As it was discussed in one of the previous posts JPA: Mapping Enums the right way, JPA 2.1 standardized AttributeConverters, which can, for example, be used to map Java enums in more controlled/predicted way. Let's quickly recap how it can be done.

Using attribute converter to map java enum

Let's assume we have a PhoneType enum and a simple entity that has this enum as a field.
To be able to map this enum into the integer column of database table, which would match enum's id we need to create an attribute converter similar to the next one:
Having such converter we can annotate the corresponding filed in the entity with the @Covert annotation and that's it! This look pretty easy and doesn't require a lot of code.
What if we have one more enum? For example let's add AddressType. The process would be very similar - we need to create an attribute converter class and add @Covert annotation on the corresponding filed.
But what if we have even more enums that should be mapped this way? This would mean that we need to write a converter for each enum and basically duplicate the same logic in each of them...

Handy utility for Enums

That's where an utility class comes. In Java it is not possible to build inheritance hierarchies of enums, but it is possible for enum to implement an interface. So if we have enums that we want to map by their id to a database columns we can create an interface similar to DbEnumConstant:
Now let's make sure that our enums implement this interface:
Now that our enums have something in common we can generalize the operation of finding an enum value by id. For example next utility static method can be introduced:
But it would mean that an array of enums is needed to be passed all the time to make a call (for example like this - Utils.findByID( dbData, PhoneType.values() )). This can be solved with usage of Class#enumConstants method. DbEnumConstantHelper can be introduced, and to make it even more useful a few more variations of find methods can be added to it:
Now having such helper class, it can be added to enums for simple access to its functionality:
Finally we can get back to attribute converters.

AttributeConverter using enum helper

Now that we have all of the above in place we can write an abstract generic attribute converter for our enums with implementations for AddressType and PhoneType:

We can see that all the conversion logic is placed in the abstract converter and implementations just need to pass a helper so the right find operations would be applied.

Conclusions 

We looked once more at how Java enums can be mapped in JPA using AttributeConverter and provided a way to reduce code duplication in such converters. Even though, at first, it might not look like this amount of code  is less then writing a simple converter. But it really pays of when you have quite a few enums to map in such a way. Also this enum helper, that was introduced, is useful outside the converters as well, it gives an easy access to finding enums by their properties.

All the code samples can be found on GitHub.

To be continued ...

Stream API received a few nice additions with the Java 9. Both Stream interfaces as well as Collectors were updated. Let's start with the new collectors. To show these improvements we will use next classes:

Flatmapping and filtering collectors

In this post we will take a look at couple of ways how many-to-many relationships, which have additional information, can be mapped to entities using JPA. @ManyToMany annotation cannot be applied in such cases as it does not allow to map additional information from the join table.

To show these approaches let's consider such small film rental database schema:
We have three main entity tables - actor, film, and customer. Where film_to_actor as well as rental can be called join tables with additional information. Actors are playing in the films as characters, and in our case an actor can play only one character in one film. This is represented by film_to_actor table. A customer can rent films, and he/she is not limited to one rent of a movie. Hence the rental table. Notice the difference between the rental and film_to_actor tables. film_to_actor has a composite key built from two foreign keys (film_id, actor_id), whereas rental has it's own id (as well as uuid similar to other main entities). Such difference is based on the business logic that we described earlier, as a pair of actor and film is unique we don't need additional id column, as for the rentals a pair of customer and film is not unique so in this case a separate id is added. This will help us show different mapping approaches.

Using @ElementCollection and Map for mapping many-to-many relationship with additional information

First thing first - we need to create a movie! After all the work on the film is finished we need to store it in the database somehow. Mapping actors and films is easy. An example of such mapping can be next:
That was easy enough, now what about a relation between films and actors? Well as, in our case, one actor can play one role in the film and actor identity defines which role it is, a Map is just asking to be used. An actor would serve as a map key and actor's role would be a value. Let's add such map to film entity as it is a logical place to store such information and map it with @ElementCollection.
Note, as there are three values that we need to map (main_character, first_name, last_name), we need to create an Embeddable to hold them all together at the same time:
In result we would have next class diagram:

If we would like to rather have information about in which films an actor played which character, we would place a Map in actor entity, where a film would be a map key and character information would be a map value.
We shouldn't have both such maps at the same time, mapping the same table using element collection. We should only either use it in Film or in Actor, but never in both. Let's give it a try and persist a film:
There are two things that we should look closer at here. First note that we need to persist actors separately, as we cannot benefit from cascading. But in a real application you would, most likely,  have actors persisted already. Next note that we are not exposing the Map to the users. Even though it's a good container to store key-value pairs it's much better and cleaner to provide methods on Film class to work with actors logic instead. Like in our test example we added a Film#addCharacter method:
which simply delegates the operation to the map. Similarly we can add a few more methods like this depending on the application needs:
This wraps the case of using element collections for mapping many-to-many relations with additional information. Let's move to another case.

Using @ManyToOne/@OneToMany and an entity to map many-to-many relationship with additional information

Java 9 brings a lot of big new features, tools and API enhancements. But somehow the most excitement comes from a few simple additions to collections at which we will look today.

JEP 269: Convenience Factory Methods for Collections

So why so many people are so excited about JEP 269? Creating a collection from a number of elements is actually an operation very frequently used in the code. How many times did you wrote something like:
Any of these options require more than one operation and creation of additional objects just to get an immutable collection. Also Arrays#asList method feels slightly out of place. That's why Java 9 introduce these static factory methods for creating immutable collections, to make the process much more easier. A number of methods is provided to cover different number of elements: There's also the same kind of methods present for List as well:
Such variety of methods is based on performance reasons. Having just one var-arg method would mean that the unnecessary array will be created all the time. Here's how the code from examples shown above would look like using Java 9:
Let's have a look at some properties of Collections created with these factory methods.

Properties of Set created with static factory methods

• are structurally immutable, which means that no element can be added or removed from it.
• disallow null as values. If null is passed a NullPointerException will be thrown.
• disallow duplicates. If duplicate elements are passed to such factory method - an IlligalArgumentException will be thrown.
• do not guarantee the iteration order through elements.

Here are a few test example covering the properties mentioned above:

Properties of List created with static factory methods

In the next post of "Code generator" series we will will talk about Immutables. This annotation processor based code generator allows you to generate simple, safe and consistent value objects, without the need to write Builders, factory methods and so on... It is easy to use, it allows customization, and all you need to do is to define your model value object as interface or abstract class.

To start using Immutables, all you need to do is to add it to your dependencies. For example with Maven project you will have:

IDE configuration

Let's see what should be done in IntelliJ IDEA to make work with Immutables easier. First we need to make sure that Annotation Processors are enabled for your project. To do this go to File > Settings > Build, Execution, Deployment > Compiler > Annotation Processors and select your module/project where you want to enable annotation processing:

"Enable annotation processing" checkbox should be checked together with "Obtain annotation processors from project classpath" option (like on the screenshot above). If they are not selected - click them and save the config. After this generated classes will appear in target subfolder. To make them visible to you in the IDE open module settings:
Select your module, and make sure that folder that contains your generated code is marked as "Sources" and "Exclude" is removed from that folder (in our case it's target/generated-sources/annotations). If you don't do this - your project will compile and work fine with Maven but not in the IDE, as generated stuff will not be visible to it.

For Eclipse configuration you can see the documentation here.

Creating value objects

Finally! Let's start creating immutable value objects. For purposes of this post we will consider a Book value object example. We will have a Book written by the Author and identified by ISBN number. Let's start with the Author:
So we see that all we need to do is define an abstract accessors to properties that we'd like our object to have and mark the class itself with @Value.Immutable. After doing this you can build the project and implementation will be generated for you, so you can start using Author objects:
You can see how builder is generated by Immutables. By default Immutables will make sure that passed values are not null:
But what if you need more validations applied? It's possible by adding check methods annotated with @Value.Check. Let's take a look at ISBN to show this: So we created another abstract class and added check method annotated with @Value.Check, which contains different kinds of checks for ISBN number. We used AssertJ Precondition methods to make a couple of checks for number validity. Note that these checks will run when you will try to construct an object - so no invalid objects should be present in your application.
Now let's combine our ISBN and Author into a Book and perform some simple manipulations on the book instance.
As you see immutable objects can be built not only from abstract classes but from interfaces as well. Generated classes also have some methods to create new objects from your immutables. Let's see some simple examples:
So we see that using Immutables allows us to save some time, as we don't need to write builders, over and over again, for each immutable object that we add, and we don't need to have properties and huge constructors, but just a list of accessor methods.
All the code from this post can be found on GitHub.

To be continued...

By this post I'll be starting a series of posts dedicated to different code generators, which makes our lives easier, and more fun. As we don't need to write boring code!

Did you ever find yourself in a situation where you needed to copy data from one Java bean to another? Or maybe from an Entity to DTO? Does next code look familiar to you ?
MapStruct to the rescue! MapStruct is an Annotation Processor based code generator. It allows you to specify mappings between Java bean types through declaring interface of such mapping. And the code generation part will provide an implementation.

For demo purposes of this post let's start with a simple example. Assume we have an @Embeddable AddressEntity class, as part of our domain model. And we'd like to create Address POJOs from this embeddable.

We could have done it with the help of a constructor:
Or maybe with a static method:
And it looks OK, and seems easy enough to write. But what if we do have more properties? A lot more properties... Or maybe we are just that lazy :). So if we would do it with MapStruct it'll look like this:
Looks easy, right?

Let's look closer at what should be done to create a mapper. First we need to create an interface (called AddressMapper in our case) and put @Mapper annotation on it. This annotation is a marker annotation for MapStruct. It'll find all mappers and generate the implementation for them. If you'd like you can make mappers from abstract classes as well, but personally I prefer interfaces.

As we would like to access our mapper somehow - INSTANCE interface member is defined. To get the generated mapper we need to call Mappers.getMapper( ... ).

Now how this would work on practice and when this code generation will happen? As it's an Annotation Processor based code generator we should include it in our build process. In case of Maven project it can be done by specifying annotation processor in Maven's compiler plugin like this:
So that was easy. But what if we have a more complex data types?

Let's consider UserEntity and User pair and create a mapper for them:
In this case, we see that we don't have one to one match between properties of both types. Some have different names (UserEntity.lastVisit and User.visit), some are inside of value objects (UserEntity.userName and UserEntity.password inside User.credentials), enum is represented as a string, and even some are missing (like id). We also have properties from previously considered addresses pair as well.
Here's a possible way to define a mapper for such type pair:
First notice that @Mapper annotation has additional uses parameter defined. It is needed as we would like our mapper to use the mappings that we defined in AddressMapper for address types. Next let's move to mapping method UserMapper#toUser. There's a few @Mapping annotations declared. It's easy to see that they allow us to define a source property and where it is located in the target type. So this will help us to handle naming mismatch, or cases where properties are inside of other beans. The only thing left to notice here is a default method UserMapper#genderToString. As we see it converts an enum - to a string. This method will be picked up by MapStruct and used in mapping enum to string. It also shows a way on how a complex mapping can be done by hand, if needed. You can provide you own mapping functions with complex logic which later can be used by MapStruct.

And here's a test to make sure that everything works as expected:
MapStruct is interesting not only because it saves time by generating mapping code, but by the concept of mapper by itself. Even if you end up with writing parts of mapping code on your own, a mapper will give you a separation of concerns and you wouldn't need any constructors or factory methods in your bean types.

All the examples with tests and configurations can be found in this GitHub repository.

To be continued...