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.

JPA 2.1 Entity Graph - Part 2: Define lazy/eager loading at runtime

This is my second post on Entity Graphs, one of the features introduced with JPA 2.1. The first post described the usage of named entity graphs. These can be used to define a graph of entities and/or attributes at compile time that shall be fetched with a find or query method. Dynamic entity graphs do to the same but in a dynamic way. This means you can use the EntityGraph API to define your entity graph at runtime.
If you have missed the first post and want to read how to define a named entity graph or how lazy loading issues were solved with JPA 2.0, check this post: JPA 2.1 Entity Graph - Part 1: Named entity graphs

Conference Report: JUG Saxony Day 2014

Last friday (2014-04-04) I visited the JUG Saxony Day 2014 in Dresden, Germany. It was the first event organized by the JUG Saxony and to make it short, it was great! The event was well organized and had lots of interesting talks.
But let's get into more details ...

The conference offered 4 tracks with 5 sessions each:

1. Software development process
2. Java technology
3. Research
4. Java mobile and enterprise applications with Java

So I had to make a hard decision to select 5 tracks for the day...