Type Casting in Java - Casting one Class to other class or interface

Type Casting in Java - Casting one Class to other class or interface

Type casting in Java is to cast one type, a class or interface, into another type i.e. another class or interface. Since Java is an Object oriented programming language and supports both Inheritance and Polymorphism, It’s easy that Super class reference variable is pointing to Sub Class object but catch here is that there is no way for Java compiler to know that a Super class variable is pointing to Sub Class object. Which means you can not call method which is declared on sub class. In order to do that, you first need to cast the Object back into its original type. This is called type-casting in Java. This will be more clear when we see an example of type casting in next section. Type casting comes with risk of ClassCastException in Java, which is quite common with method which accept Object type and later type cast into more specific type. we will see when ClassCastException comes during type casting and How to avoid it in coming section of  this article. Another worth noting point here is that from Java 5 onwards you can use Generics to write type-safe code to reduce amount of type casting in Java which also reduces risk of java.lang.ClassCastException at runtime. 

What is type casting in Java

From first paragraph, we pretty much know What is type casting in Java. Anyway, In simple words type casting is process of converting one type, which could be a class or interface to another, But as per rules of Java programming language only classes or interfaces (collectively known as Type) from same Type hierarchy can be cast or converted into each other. If you try to cast two object which doesn't share same type hierarchy, i.e. there is no parent child relationship between them, you will get compile time error. On the other hand if you type cast objects from same type hierarchy but the object which you are casting are not of the same type on which you are casting then it will throw ClassCastException in Java. Some people may ask why do you need type casting? well you need type casting to get access of fields and methods declared on target type or class. You can not access them with any other type. Let's see a simple example of type casting in Java with two classes Base and Derived which shares same type hierarchy.

Type casting example in Java

In this Example of type casting in Java we have two classes, Base and Derived. Derived class extends Base i.e. Base is a Super class and Derived is a Sub class. So there type hierarchy looks like following tree :

Base

 |

Derived

Now look at following code :

Base b = new Derived(); //reference variable of Base class points object of Derived class
Derived d = b; //compile time error, requires casting
Derived d = (Derived) b; // type casting Base to Derived

Above code type casting object of Derived class into Base class and it will throw ClassCastExcepiton if b is not an object of Derived class. If Base and Derived class are not related to each other and doesn't part of same type hierarchy, cast will throw compile time error. for example you can not cast String and StringBuffer, as they are not from same type hierarchy.

Type-casting and ClassCastExcepiton in Java

As explained in last section type casting can result in ClassCastException in Java. If the object you are casting  is of different type. ClassCastException is quite common while using Java collection framework classes e.g. ArrayList, LinkedList or HashSet etc because they accept object of type java.lang.Object, which allows insertion of any object into collection. let's a real life example of ClassCastException in Java during type casting :

ArrayList names = new ArrayList();
names.add("abcd"); //adding String
names.add(1);   //adding Integer

String name = (String) names.get(0); //OK
name = (String) names.get(1); // throw ClassCastException because you can not convert Integer to String

In above example we have an ArrayList of String which stores names. But we also added an incorrect name which is Integer and when we retrieve Object from collection they are of type java.lang.Object which needs to be cast on respective for performing operation. This leads into java.lang.ClassCastException when we try to type cast second object, which is an Integer, into String. This problem can be avoided by using Generics in Java which we will see in next section.

Generics and Type Casting in Java

Generics was introduced in Java 5 along with another type-safe feature Enum, which ensures type safety of code during compile time, So rather you getting ClassCastException during runtime by type casting you get compile timer error why your code violate type safety. Use of Generics also removes casting from many places e.g. now while retrieving object from Collection you don't need to type cast into respective type. Here is the modified version of same code which is free of ClassCastException because use of Generics :

ArrayList<String> names = new ArrayList<String>(); //ArrayList of String only accept String
names.add("abcd");
names.add(1);   //compile time error you can not add Integer into ArrayList of String

String name =  names.get(0); // no type casting requires

If you are new to Generics, those angle bracket denotes type. to learn more about Generics, See How Generics works in Java.

Spring MVC’s Default Behavior

View Resolver

First up is the view resolver. We can’t specify all the views ahead of time and the only way the marketing department communicates new pages to us is by publishing them into our JSP directory, Springs InternalResourceViewResolver is the perfect fit.

<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/jsp/content/" /> <property name="suffix" value=".jsp" /> </bean>

Assuming the build script pulls the published HTML files into the projects /WEB-INF/jsp/content directory and renames them with a “.jsp” extension, then all the pages should be available with a view that matches the path to the page, minus the ViewResolver’s specified prefix and suffix. For example, if we have a page stored at /WEB-INF/jsp/content/members/profile.jsp, A controller can access that page by returning a view name of members/profile.

The Default Controller

Now that there is a view resolver capable of seeing all the pages produced by the marketing department, a controller must be created and mapped so that it will produce the correct view name.

package com.sourceallies.base;   import org.springframework.stereotype.Controller; import org.springframework.web.bind.annotation.RequestMapping;   @Controller public class DefaultController {   @RequestMapping("/**/*") public void defaultRequest(){} }

That was easy. It would be hard to come up with a simpler controller, in fact it doesn’t look like it does anything at all! In reality it is taking advantage of Spring MVC’s default behavior for just about everything. With annotation based controllers, request mapped methods have a variety of possible return types. Strings are interpreted as view names, and ModelView objects are used like they were in previous versions of Spring MVC. But if the method has no return type then we get some interesting behavior. On void methods (or String methods that return null) Spring MVC looks at the request URI, strips off the app context and any file extensions, and uses whatever is left over as the view name. For example, if my application is mapped to /corporate/ and my request URL is /corporate/members/profile.html then Spring MVC will generate a view name of “members/profile”. The other thing to note is the RequestMapping, /**/* is the most generic mapping there is. It will match any request that comes through the Spring MVC servlet. This is how to avoid having to add new mappings for every new page. This is exactly what we want to use when working with the ViewResolver we defined earlier. All of the pages from the CMS live relative to each other, and the URLs requested from the client should match the file structure from the CMS.
So at this point I now have a more complicated version of the normal servlet request process. Its usefulness becomes apparent when marketing needs a new piece of data on a specific page and I need to create a controller.

@Controller public class ProfileController {   @RequestMapping("/members/profile.html") public void testRequest(Model model) { Profile profile = ...LookupProfile   model.addAttribute("profile", profile); } }

All I have to do is create a new controller and map it to the page name from the marketing department.

Understanding Spring MVC Model and Session Attributes

Spring MVC Scopes

When I started writing Web applications in Spring MVC, I found the Spring model and session attributes to be a bit of a mystery – especially as they relate to the HTTP request and session scopes and their attributes that I knew well.  Was a Spring model element going to be found in my session or request?  If so, how could I control this?  In this post, I hope to demystify how Spring MVC’s model and session work.

Spring’s @ModelAttribute

There are several ways to add data or objects to Spring’s model.  Data or objects are typically added to Spring’s model via an annotated method in the controller.  In the example below, @ModelAttribute is used to add an instance of MyCommandBean to the model under the key of “myRequestObject”.

@Controller

public class MyController {

 

    @ModelAttribute("myRequestObject")

    public MyCommandBean addStuffToRequestScope() {

        System.out.println("Inside of addStuffToRequestScope");

        MyCommandBean bean = new MyCommandBean("Hello World",42);

        return bean;

    }

 

    @RequestMapping("/dosomething")

    public String requestHandlingMethod(Model model, HttpServletRequest request) {

        System.out.println("Inside of dosomething handler method");

 

        System.out.println("--- Model data ---");

        Map modelMap = model.asMap();

        for (Object modelKey : modelMap.keySet()) {

            Object modelValue = modelMap.get(modelKey);

            System.out.println(modelKey + " -- " + modelValue);

        }

 

        System.out.println("=== Request data ===");

        java.util.Enumeration reqEnum = request.getAttributeNames();

        while (reqEnum.hasMoreElements()) {

            String s = reqEnum.nextElement();

            System.out.println(s);

            System.out.println("==" + request.getAttribute(s));

        }

 

        return "nextpage";

    }

 

         //  ... the rest of the controller

}

On an incoming request, any methods annotated with @ModelAttribute are called before any controller handler method (like requestHandlingMethod in the example above).  These methods add data to a java.util.Map that is added to the Spring model before the execution of the handler method.  This can be demonstrated by a simple experiment.  I created two JSP pages:  index.jsp and nextpage.jsp.  A link on index.jsp page is used to send a request into the application triggering the requestHandlingMethod() of MyController.  Per the code above, the requestHandlingMethod() returns “nextpage” as the logical name of the next view which is resolved to nextpage.jsp in this case.



When this little Web site is executed in this fashion, the System.out.println’s of the controller, show how the @ModelAttribute method is executed before the handler method.  It also shows that the MyCommandBean was created and added to Spring’s model and was available in the handler method.

Inside of addStuffToRequestScope

Inside of dosomething handler method

--- Model data ---

myRequestObject -- MyCommandBean [someString=Hello World, someNumber=42]

=== Request data ===

org.springframework.web.servlet.DispatcherServlet.THEME_SOURCE

==WebApplicationContext for namespace 'dispatcher-servlet': startup date [Sun Oct 13 21:40:56 CDT 2013]; root of context hierarchy

org.springframework.web.servlet.DispatcherServlet.THEME_RESOLVER

==org.springframework.web.servlet.theme.FixedThemeResolver@204af48c

org.springframework.web.servlet.DispatcherServlet.CONTEXT

==WebApplicationContext for namespace 'dispatcher-servlet': startup date [Sun Oct 13 21:40:56 CDT 2013]; root of context hierarchy

org.springframework.web.servlet.HandlerMapping.pathWithinHandlerMapping

==dosomething.request

org.springframework.web.servlet.HandlerMapping.bestMatchingPattern

==/dosomething.*

org.springframework.web.servlet.DispatcherServlet.LOCALE_RESOLVER

==org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver@18fd23e4

Now, the question is “where is Spring model data stored?”  Is it stored in the standard Java request scope?  The answer is – yes… eventually.  As you can tell from the output above, MyCommandBean is in the model, but not yet in the request object when the handler method executes.  Indeed, Spring does not add the model data to the request as an attribute until after the execution of the handler method and before presentation of the next view (in this case the nextpage.jsp).

This can also be demonstrated by printing out the attribute data stored in the HttpServletRequest in both index.jsp and nextpage.jsp.  I arranged for both of these pages to use a JSP scriptlet (shown below) to display the HttpServletRequest attributes.

<hr />

<h3>Request Scope (key==values)</h3>

<%

    java.util.Enumeration<String> reqEnum = request.getAttributeNames();

    while (reqEnum.hasMoreElements()) {

        String s = reqEnum.nextElement();

        out.print(s);

        out.println("==" + request.getAttribute(s));

%><br />

<%

    }

%>

When the application comes up and index.jsp is displayed, you can see that there are no attributes in request scope.

In this case, when the “do something” link is clicked it causes the MyController’s handler method to execute, which in turn causes the nextpage.jsp to be displayed.  Given the same JSP scriptlet is on the nextpage.jsp, it too renders what is in the request scope.  Lo and behold, when nextpage.jsp renders, it shows the model MyCommandBean created in the controller has been added to the HttpServletRequest scope!  The Spring model attribute key of “myRequestObject” has even been copied and used as the request attribute’s key.
So Spring model data created prior to (or during) the handler method execution has been copied to the HttpServletRequest before the next view is rendered.

Spring’s @SessionAttributes

So now you know how Spring’s model data is managed and how it relates to regular Http request attribute data.  What about Spring’s session data?
Spring’s @SessionAttributes is used on a controller to designate which model attributes should be stored in the session.

In actually, what @SessionAttributes allows you to do is tell Spring which of your model attributes will also be copied to HttpSession before rendering the view.  Again, this can be demonstrated with a little code.

In my index.jsp and nextpage.jsp, I added an additional JSP scriptlet to show the HttpSession attributes.

<h3>Session Scope (key==values)</h3>

<%

  java.util.Enumeration<String> sessEnum = request.getSession()

    .getAttributeNames();

  while (sessEnum.hasMoreElements()) {

    String s = sessEnum.nextElement();

    out.print(s);

    out.println("==" + request.getSession().getAttribute(s));

%><br />

<%

  }

%>

I annotated MyController with @SessionAttributes to put the same model attribute (myRequestObject) in Spring session.

@SessionAttributes("myRequestObject")

public class MyController {

  ...

}

 

I also added code to the handler method of my controller to show what attributes are in HttpSession (just as it shows what attributes are in HttpServletRequest).

@SuppressWarnings("rawtypes")

@RequestMapping("/dosomething")

public String requestHandlingMethod(Model model, HttpServletRequest request, HttpSession session) {

  System.out.println("Inside of dosomething handler method");

 

  System.out.println("--- Model data ---");

  Map modelMap = model.asMap();

  for (Object modelKey : modelMap.keySet()) {

    Object modelValue = modelMap.get(modelKey);

    System.out.println(modelKey + " -- " + modelValue);

  }

 

  System.out.println("=== Request data ===");

  java.util.Enumeration<String> reqEnum = request.getAttributeNames();

  while (reqEnum.hasMoreElements()) {

    String s = reqEnum.nextElement();

    System.out.println(s);

    System.out.println("==" + request.getAttribute(s));

  }

 

  System.out.println("*** Session data ***");

  Enumeration<String> e = session.getAttributeNames();

  while (e.hasMoreElements()){

    String s = e.nextElement();

    System.out.println(s);

    System.out.println("**" + session.getAttribute(s));

  }

 

  return "nextpage";

}

So now, we should be able to see what is in the session object before, during, and after Spring MVC has handled one HTTP request when annotated with @SessionAttributes.  The results are shown below.  First, as the index.jsp page is displayed (before the request is sent and handled by Spring MVC), we see that there is no attribute data in either the HttpServletRequest or HttpSession.

During the execution of the handler method (requestHandlingMethod), you see MyCommandBean has been added to the Spring model attributes, but it is not yet in the HttpServletRequest or HttpSession scope.
But after the handler method has executed and when the nextpage.jsp is rendered, you can see that the model attribute data (MyCommandBean) has indeed been copied as an attribute (with the same attribute key) to both HttpServletRequest and HttpSession.

Controlling Session Attributes

So now you have an appreciation of how Spring model and session attribute data are added to HttpServletRequest and HttpSession. But now you may be concerned with how to manage that data in Spring session. Spring provides a means to remove Spring session attributes, and thereby also remove it from HttpSession (without having to kill the entire HttpSession). Simply add a Spring SessionStatus object as a parameter to a controller handler method. In this method, use the SessionStatus object to end the Spring session.

@RequestMapping("/endsession")

public String nextHandlingMethod2(SessionStatus status){

  status.setComplete();

  return "lastpage";

}

@RequestMapping("/endsession")

public String nextHandlingMethod2(SessionStatus status){

  status.setComplete();

  return "lastpage";

}

Hibernate’s and LazyInitializationExceptions

For many years LazyInitializationExceptions have become most frustrating point of Hibernate. This exception occurs when you try to access an un-initialised lazy association of a detached entity.
Entities become detached in three different ways;

• session close
• session clear
• session evict

You have to be sure that any lazy attributes you will access be initialised before those three cases happen. Otherwise you will come up with the infamous Lazy exception.
So what are the ways to get rid of that Lazy exception? There are several ways available in Hibernate and employed among the community;

• You can invoke Hibernate.initialize(proxy) on each lazy attribute before their owning entity becomes detached.
• You have to access their specific properties such as ids before detachment such as x.getLazySet().size() or x.getLazyManyToOneAssoc().getId().
• For web applications you can also employ OpenSessionInViewFilter which keeps session open until the end of view render process so that entities wont become detached before those lazy attributes accessed.
• You can also reattach detached entities before accessing their lazy attributes using session merge or lock operations.

With Hibernate 4.1.6 a new feature is introduced to handle those lazy association problems. When you enable hibernate.enable_lazy_load_no_trans property in hibernate.properties or in hibernate.cfg.xml, you will have no LazyInitializationException any more. It works for any sort of lazy associations not only many sided (1:M, N:M) but also one sided (1:1,:M:1) as well.
So what does this property do? It simply signals Hibernate that it should open a new session if session which is set inside current un-initialised proxy is closed. You should be aware that if you have any other open session which is also used to manage current transaction, this newly opened session will be different and it may not participate into the current transaction unless it is JTA. Because of this TX side effect you should be careful against possible side effects in your system.
Another important point is that this feature only works for proxies whose sessions are closed or their owning entity is evicted from the session. If the entity become detached with session clear then you will still have the lazy problem. According to code comments in Hibernate’s AbstractPersistentCollection class, Hibernate team aims to handle session clear in the next major release.

Flushing Hibernate

Flushing Hibernate

Today I am going to write about Hibernate flushing. Do not worry, I am not going to flush Hibernate to the toilet. I will write about the way, how Hibernate propagates changes to the database.
When you are modifying data using Hibernate, you have to keep in mind that Hibernate uses so called write-behind. It means that Hibernate propagates changes to the database as late as possible. By default this propagation (flushing) happens at the following times

• when transaction is committed
• before query is executed
• when flush() method is called explicitly

Usually such behavior is a good thing. It enables Hibernate to optimize data modifications and allows grouping many changes to one big batch update. But sometimes you can encounter some interesting issues. Lets show it on some example. Lets have following entity class:

01 @Entity 02 public class Client  { 03    04   @Id @GeneratedValue(strategy=GenerationType.AUTO) 05   private Long id; 06 07   @Column(unique=true,nullable=false) 08   private String personalNumber; 09    10   @Column 11   private String name; 12    13   . 13   . 13   . 14 }

We see that a client has id which is used internally as an identifier. Moreover a client has a personal number which we are using as a business key. Then he has some other attributes as name. Notice that the personal number is obligatory and it has to be unique.

01     Client client = new Client(PERSONAL_NUM);
02     LOG.debug("Creating first client");
03     clientDao.createClient(client);
04     
05     LOG.debug("Changing first client");
06     client.setName("Carl von Bahnhof");
07     
08     LOG.debug("Deleting first client");
09     clientDao.deleteClient(client.getId());
10     
11     LOG.debug("Trying to load first client");
12     assertNull(clientDao.loadClientWithPersonalNumberOrReturnNull(PERSONAL_NUM));
13     
14     LOG.debug("Creating second client");
15     clientDao.createClient(new Client(PERSONAL_NUM));
When it is executed on HSQLDB we get following output (we see my logging messages mixed with Hibernate SQL output).


Creating first client
insert into Client (name, personalNumber, id) values (?, ?, ?)
call identity()
Changing first client
Deleting first client
Trying to load first client
delete from Client where id=?
select client0_.id as id2_, client0_.name as name2_, client0_.personalNumber as personal3_2_ from Client client0_ where client0_.personalNumber=?
Creating second client
insert into Client (name, personalNumber, id) values (?, ?, ?)
call identity()


We see that inserts are called at once. They are not postponed until flush. In this case, Hibernate has to call insert at once because it has to get the client id from the database. (remember all non-transient entities have to have id) So inserts can not wait until flush, they have to be executed directly. In order to make our example more clear, we can change id generation strategy to sequence.

01 @Entity 02 public class Client  { 03    04   @Id @GeneratedValue(strategy=GenerationType.SEQUENCE) 05   private Long id; 06 07   @Column(unique=true,nullable=false) 08   private String personalNumber; 09    10   @Column 11   private String name; 12    13   . 14   . 15   . 16 }

To get the client id, insert is not needed any more. It can be postponed until flush and we get following output

Creating first client
select next value for hibernate_sequence from dual_hibernate_sequence
Changing first client
Deleting first client
Trying to load first client
insert into Client (name, personalNumber, id) values (?, ?, ?)
delete from Client where id=?
select client0_.id as id2_, client0_.name as name2_, client0_.personalNumber as personal3_2_ from Client client0_ where client0_.personalNumber=?
Creating second client
insert into Client (name, personalNumber, id) values (?, ?, ?)

As you can see creation of the first client and his deletion is realized just before the select statement. Changes have to be propagated to the DB so the select statement has access to changed data. You can notice, that there is no update, change of the name was already included into the insert statement. So far so good. Where is the problem? Lets comment out the query (You do not have to comment it out, in the real world it can be bypassed by the second-level cache).

01     Client client = new Client(PERSONAL_NUM); 02     LOG.debug("Creating first client"); 03     clientDao.createClient(client); 04      05     LOG.debug("Changing first client"); 06     client.setName("Carl von Bahnhof"); 07      08     LOG.debug("Deleting first client"); 09     clientDao.deleteClient(client.getId()); 10      11     //LOG.debug("Trying to load first client"); 12     //assertNull(clientDao.loadClientWithPersonalNumberOrReturnNull(PERSONAL_NUM)); 13      14     LOG.debug("Creating second client"); 15     clientDao.createClient(new Client(PERSONAL_NUM));

We get following output

Creating first client
select next value for hibernate_sequence from dual_hibernate_sequence
Changing first client
Deleting first client
Creating second client
insert into Client (name, personalNumber, id) values (?, ?, ?)
insert into Client (name, personalNumber, id) values (?, ?, ?)
SQL Error: 0, SQLState: null
failed batch
Could not synchronize database state with session
org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update
at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:237)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:54)
at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:438)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:662)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:632)
at org.springframework.test.context.transaction.TransactionalTestExecutionListener.endTransaction(TransactionalTestExecutionListener.java:346)
at org.springframework.test.context.transaction.TransactionalTestExecutionListener.afterTestMethod(TransactionalTestExecutionListener.java:199)
at org.springframework.test.context.TestContextManager.afterTestMethod(TestContextManager.java:340)
at org.springframework.test.context.junit4.SpringMethodRoadie.runAfters(SpringMethodRoadie.java:351)
at org.springframework.test.context.junit4.SpringMethodRoadie.runBeforesThenTestThenAfters(SpringMethodRoadie.java:262)
at org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:234)
at org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:204)
at org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:146)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:151)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.sql.BatchUpdateException: failed batch
at org.hsqldb.jdbc.jdbcStatement.executeBatch(Unknown Source)
at org.hsqldb.jdbc.jdbcPreparedStatement.executeBatch(Unknown Source)
at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297)
at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246)
... 31 more

Wow. It looks like Hibernate is trying to insert both clients with the same personal number without deleting the first one. Lets try to remove uniqueness condition from the client and take a look at the output:

Creating first client
select next value for hibernate_sequence from dual_hibernate_sequence
Changing first client
Deleting first client
Creating second client
insert into Client (name, personalNumber, id) values (?, ?, ?)
insert into Client (name, personalNumber, id) values (?, ?, ?)
delete from Client where id=?

Yes, Hibernate changed order of the commands! Without the unique constraint it does not matter, final result is the same. But with the constraint enabled, we can not use our code any more. Is it a bug? No, it is a feature. If you dig deep into the Hibernate source code, you will find following comment

Execute all SQL and second-level cache updates, in a
special order so that foreign-key constraints cannot
be violated:

1. Inserts, in the order they were performed
2. Updates
3. Deletion of collection elements
4. Insertion of collection elements
5. Deletes, in the order they were performed

And that is exactly our case. When flushing, Hibernate executes all inserts before delete statements.
So if we need to run our example, we have to force Hibernate to flush the delete before the second insert. The best way is to call entityManager.flush() explicitly just after the delete.
To reiterate, Hibernate is using write-behind. All data manipulating statements are executed as late as possible. One exception are insert statements. Sometimes Hibernate needs to call insert in order to get the ID of the entity. The important point is, that order of the commands can be changed by Hibernate. Usually it does not matter, since transactions are atomic. But sometimes we can encounter interesting issues. Especially when using database constraints.