Cheat Sheet: New Features in JPA 2.1

JPA 2.1 introduced 12 new features, like StoreProcedureQueries, Entity Graphs and Attribute Converter, to make your work with the database easier and more efficient.
Download your free New Features in JPA 2.1 cheat sheet now, to get all the information you need to improve your database access.

This 5 page cheat sheet brings you:

- a short description and
- code snippets for each feature,
- links to more detailed articles.

Signup now and get your free New Features in JPA 2.1 cheat sheet and regular blog updates.

I respect your privacy and have ZERO TOLERANCE for spam!

Java Weekly #4: PicketLink and DeltaSpike, Batch API, JMS 2.1 and more...

Java EE

Shane Bryzak wrote a great article on how to use PicketLink and Apache DeltaSpike to secure your Java EE application. The combination of these two frameworks is really powerful. It allows you to add security to your application by implementing only one annotation and one method.


The Batch 1.0 API does not offer any solution to schedule a batch operation in Java EE. But there is no need for it, as Arun Gupta shows in his Tech Tip #36. The Java EE plattform already offers 3 different ways to schedule a batch operation.


If you want to learn more about the Java EE Concurrency API, you should have a look at the Java EE Concurrency API Tutorial by Francesco Marchioni. He created a detailed description on how to process parallel tasks on a Java EE application server. This is really a great resource if you want to learn more about Java EE Concurrency.

Java Weekly #3: Microservices, Java 8 features, upcoming events and more...

Java

The article Tired of Null Pointer Exceptions? Consider Using Java SE 8's Optional! by Raoul-Gabriel Urma gives an extensive description about how to use Optional to improve your API and avoid NullPointerExceptions.


Oleg Shelajev wrote an interesting article about the unpredictability of parallel streams. The stream API is one of the major features introduced with Java 8 and it seems to be easy and powerful. But as Oleg describes in his article, it can influence the performance of your application in an unpredictable way.


Java EE

Maven archetypes are a quick and easy way to setup a Maven project and immediately start with the implementation. But so far there was no archetype to create a Java EE 7 project with Arquillian dependencies and profiles (at least as far as I know...). If you have used Arquillian to test your application, you know that setting up the profiles for different application servers is always some annoying (copy & paste) work.
This has changed since Arun Gupta introduced a Maven Archetype for Java EE 7 projects with Arquillian profiles on his blog. The archetype provides Java EE 7 dependencies and creates a managed and a remote profile for Wildfly and GlassFish.

Java Weekly #2: JPA 2.1, Java8, JSR 351, Eclipse Luna and more...

Java EE

Steven Gertiser showed a great example on how to use a JPA Type Converter to persist the new Java8 DateTime classes. This example shows again how powerful the type converter feature is. You only need a few lines of code to define how a class gets persisted to the database.
If you like to read more about Type Converter and other new features of JPA 2.1, have a look at my JPA 2.1 related posts.


Normally, I try to ignore the Spring vs. Java EE discussion, but I found a good posting by Nmpallas this week. He is a long time Java EE developer and gave Spring a try for a recent project. His main reason was, that an application server offers much more features than he needed. But after some time, he decided to migrate the application to Wildfly 8.0.0. Read about his reasons and what he thinks about the standard Spring arguments in: It’s not Spring anymore is the summer of JEE7, ready riding the wave?


Java 8

Java 8 introduced the two default methods forEach(Consumer action) and spliterator() to the Iterable interface. While this looks good in the first place, Stephen Colebourne is not as happy with it. He describes in his blog why this change reduced the number of use cases of the Iterable interface: Java 8 - Iterable woes
I do not see a huge issue in this change. But what do you think? Is this really a drawback of the new Iterable interface?

Java EE Pitfalls #1: Ignore the default lock of a @Singleton

EJB Singleton Beans were introduced by the EJB 3.1 specification and are often used to store cached data. This means, we try to improve the performance of our application by using a Singleton. In general, this works quite well. Especially if there are not too many calls in parallel. But it changes if we ignore the default lock and the number of parallel calls increases.

Java Weekly #1: CDI, Java8, Bean Validation and more...

CDI

Are you familiar with CDI events? Really?
Well, then you might skip the beginning of the article You think you know everything about CDI events… Think again! by Antoine Sabot-Durand. He gives a great overview about how CDI events work and their (current) drawbacks. And he gives a small sneak peak at the changes we can expect with CDI 2.0.
This is by far the best overview about CDI events I have read so far. Everyone who is using them, should have a look at it.


The Apache DeltaSpike team released version 1.0 this week. You can find the release notes here and a short overview about the different modules in this posting by Rafael Benevides.
DeltaSpike looks really interesting and seems to provide several features I have missed or found quite complicated to implement. I have never used it so far, but I am planning to change that. If anyone of you has some real world experience with it, please write a comment. I love to hear about it.


Java 8

Oleg Shelajev takes a critical look at the usage of default methods introduced with Java 8. His main point is, that the usage of default methods can make it really difficult to understand your code. If you combine default methods of different interfaces with inheritance, it can become really difficult to find which method implementation will be executed. Therefore, you should think carefully before using default methods everywhere. Quiet often you can use inheritance to get to the same result.
I really liked his post. It is tempting to use new features as often as possible. But we always need to be aware of possible drawbacks. And a loss of readability and an increased complexity of our code can be a massive drawback if you or one of your colleagues has to change or analyze the code.

Testing with Aliens: How to test a JPA type converter with Arquillian

This post was written together with +Aslak Knutsen (@aslakknutsen).

JPA type converters provide an easy way to define how an entity attribute gets persisted to the database. You can use them to implement lots of different features, e.g. to encrypt your data as I showed in a previous post: How to use a JPA Type Converter to encrypt your data
But writing the type converter is not enough. We also need to make sure, that it is working correctly.

In general, there are two ways to test a type converter. We could write a unit test to check, if the conversion works correctly. But a unit test performs a test of the isolated class without putting it into the real execution environment. That means that we will still not know, if the converter works in one of our applications. If everything is set up correctly, the persistence provider will call the converter before writing to and after reading from the database. So we also need to check if the type converter gets called by the persistence provider and if everything works fine under that condition. We need to test the converter inside of the container we want to use for our application.
We will have a look at how this can be done with Arquillian and its persistence extension.

How to use a JPA Attribute Converter to encrypt your data

A few days ago, I read an interesting article by Bear Giles about Database encryption using JPA listeners from 2012. He discusses his requirements for an encryption solution and provides a code example with JPA listeners. His main requirements are:
  • provide a transparent encryption that does not affect the application,
  • be able to add the encryption at deployment time,
  • develop application and security/encryption by two different teams/persons.
And I completely agree with him. But after 1.5 years and a spec update to JPA 2.1, JPA listeners are not the only solution anymore. JPA 2.1 introduced Attribute Converter, which can be used to create a maybe better solution.