Saving enum values in a relational database is a bit more tricky than primitives, Strings, and regular immutable value wrappers. From this post, you’ll learn different methods for saving Java enums in a relational database using JPA. I’ll compare these methods and present the best application for them.Continue reading “Saving Java enum in database as String”
Every programmer agrees naming classes is highly important for code readability. Proper naming decrease the time needed to understand the code base. Many developers will also agree that class naming isn’t easy. There are numerous queries around the best practices which come not only from the beginners.
The aim of this article is to put in one place answers for the most popular questions around Java class name conventions and community standards. I’ll cover technical Java language restrictions, common conventions, and popular class naming best practices.
So much by way of introduction. Let’s get down into it.
The object equals contract indicates that when two objects are equal, their hash codes must also be the same. It’s a general agreement for all Java objects used in hash-based collections. Its main purpose is to optimize performance when working e.g. with HashMap or HashSet.
You may hear that when you implement the equals() method for your class, you should also implement the hashCode() method. That’s the practical approach for fulfilling the equals contract.
If you want to know more details why the contract is so important, keep on reading.
Continue reading “What is Java object equals contract?”
When you design a method in a Java class, some parameters may be optional for its execution. No matter it is inside a DTO, a fat model domain object, or a simple stateless service class, optional method parameters are common.
From this article you will learn how to handle optional parameters in Java. We’ll focus on regular method, class constructors with optional fields, and quickly look at bad practices of the discussed topic. We’ll stop for a moment to look at Java 8 Optional and assess if it fits our needs.
Let’s get started.
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.
The package is a fundamental concept in Java and one of the first things you stumble upon when starting programming in the language. As a beginner you probably don’t pay much attention to the structure of packages, but as you become a more experienced and mature software developer, you start to think what can be done to improve their clarity.
There are a few major options to consider and picking the right one might not be an obvious choice. This article should give you an overview of commonly selected strategies for structuring Java packages.
So let’s get down to it.
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.
Some validation constraint can be applied to several different types. For instance the @Size annotation works with collections, arrays, and strings. This post is a guide on how to create a validation constraint which can be applied to different data types just like the aforementioned @Size 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.