Category Archives: Java

Cross field validation

All built-in JSR 303 constraint annotations are intended to verify particular fields of our data classes. Yet, it is not unusual that several fields are connected to each other and should be checked as a unity. For instance, a field can be required only if another field is set. @NotNull won’t work in such case as there is no way to introduce the condition logic. In this post you will learn how to write a validator applicable to multiple class fields.

Continue reading Cross field validation

Facebooktwittergoogle_plusredditlinkedinmail

Custom parametrized validation annotation

In the previous post you could learn how to create a basic custom constraint annotation compatible with the Bean Validation standard. This demo will extend the former post by explaining how to create constraints which are more flexible due to parameters defined for particular use cases. If you’re totally unfamiliar with the topic, I refer you to the aforementioned post to grasp the essentials. Otherwise, just keep reading.

Continue reading Custom parametrized validation annotation

Facebooktwittergoogle_plusredditlinkedinmail

Java 8 Optional use cases

It’s been almost two years since Java 8 was officially released and many excellent articles about new enhancements and related best practices have been written through that time. Surprisingly, one of the more controversial topics amongst all the added features is the Optional class. The type is a container, which can be either empty or contain a non-null value. Such construction reminds the user of an Optional object that the situation when there’s nothing inside must be handled appropriately. Although the definition of the type on Javadoc is quite descriptive, when it comes to identifying valid use cases it’s getting more problematic.

This article has also been published on DZone.

Continue reading Java 8 Optional use cases

Facebooktwittergoogle_plusredditlinkedinmail

JEE and the myth of portability

Have you ever been in that conversation in which you had to choose between two or more frameworks/libraries and one of them was so-called JEE standard? Usually a person who advocates for it explains that thanks to standardized API it’s possible to switch the implementation to any vendor whenever needed without a worry that something in our application breaks. In theory, it sounds tempting, but does practice prove it? I’m going to focus on simple case using JAX-RS to verify the assertion.

Continue reading JEE and the myth of portability

Facebooktwittergoogle_plusredditlinkedinmail