If you want to have a good introduction to the topic EJB 3.0, I can recommend you the book “Mastering Enterprise JavaBeans 3.0”. This book can be freely downloaded from TheServerSide.com.

I am currently preparing for the SCBCD 5.0 and in my opinion, it’s better than the book “Enterprise JavaBans 3.0” from O’Reilly. “Mastering EJB 3.0” covers many topics about Java EE much deeper. For example, it mentions poison messages or clustering as  has a very useful overview of all possible annotations in the appendix.

Only the part JPA is not covered as deep as in the O’Reilly book. EmbededId is only mentioned, but not described in detail.

In Eclipse, there is a nice feature to clean up Java code. First, you can change the Clean Up profile (Window – Preferences) and define, how you want the code should look like.

There are interesting clean ups like “Remove unnecessary casts” or to add missing Annotations like “@Override”.

After creating your profile, simply right click to the project and choose Source – Clean up.

Nice feature. If you want to know more about this feature, you will find here more information’s.

In this post, I will cover again the topic JiBX. This time, I will focus on a very special case, the bidirectional mapping with JiBX. To realize that without affecting a currently used domain model (as it will happen if we use pre-set, as described in http://jibx.sourceforge.net/tutorial/binding-extend.html), we need to implement an JiBX Marshaller and an JiBX Unmarshaller.

But let me start with the simple problem. We do have two simple POJOs, Customer and Person, which do know each other. If you are using for example Hibernate, bidirectional linking is not a rarity. With the JiBX binding XML we used in our last examples, the bidirectional linking is not set. To demonstrate this, I added these two lines of code in the main application:

System.out.println(customer.toString());
System.out.println(customer.getPerson().getCustomer().toString());

The second line will result in a NullPointerException, because JiBX is not setting this bidirectional linking. To get that working without affecting the two classes Customer and Person (!), we have to create our own Marshaller and Unmarshaller.

First of all, we have to prepare our mapping file. The best way for a bidirectional mapping is to define an own mapping section for the class Person (which was previously part of the Customer mapping part).

The reason for this step is simple, but important. Our customized Unmarshaller should let JiBX unmarshal the Person into an object and our Unmarshaller should only extend the object with the bidirectional mapping to the Customer. For this reason, JiBX needs an own mapping section for this class.

After preparing the JiBX mapping, our next step is to create a Marshaller and Unmarshaller class. For the bidirectional mapping, we will just need an Unmarshaller. But because we do have a JiBX mapping file for both directions, we do have to define a Marshaller and a Unmarshaller. 
We create for this example a new class with the name BidirectionalMapper, which implements the interfaces IMarshaller, IUnmarshaller and IAliasable. These Interfaces are delivered with the JiBX libraries. In the implementation, there are two remarkable parts in the method unmarshal. The first one just forwards the real unmarshalling action to the JiBX context and the second one creates the bidirectional linking.

Object unmarshalledObject = ctx.unmarshalElement();
Person person = (Person) unmarshalledObject;
...
Object parent = ctx.getStackObject(0);
person.setCustomer((Customer) parent);

In the marshal method, we also let JiBX marshal our person. Because the bidirectional linking has no affect to this method, this method is just simple.

ctx.marshalCollection(listOfElements);

After we created our Mapper, we need to define the marshallers in the JiBX mapping file. For this reason, we expand the element structure with the marshaller and unmarshaller class path.

If we run now our application again, there is no NullPointerException anymore and we can use our previously used domain model without changing anything at these classes.

If you are interested, you can download the whole eclipse project with all the sources from here.

In a software project, Software Engineers need to ensure, that the source code meets the architectural rules. One of a usual architecture rule are the dependencies between the layer and packages. There are a lot of tools, which can be used to ensure, that no class breaks this rules.

If you know, that there are some specific classes, which do not meet these rules, a dependency code analysis is needed. Therefore, I found a free tool called CDA (http://www.dependency-analyzer.org/), which is very helpful in such a situation. It can also be used for repeated check to ensure architecture compatibility, but in this blog entry, I will focus on code analysis.

First of all, just install this tool as described on the website (http://www.dependency-analyzer.org/#Installation). CDA doesn’t need any installation (just unzip the compressed file) and can be run with Java 1.5.

After finishing the installation procedure, you need to create for every project a Workset. A Workset can contain different code sources, which are analysed together. First, define a Name. After that, go to the Classpath register. The easiest way to use CDA is to analyse a JAR file. Add all JAR files, which you want to analyse.

If you are finished, save the Workset. CDA will load now all classes from the JAR files into a tree. With CTRL + F you can search for a specific class or you can navigate with the package name to a specific class. With right click, you can analyse all dependencies (on which classes/packages does the class depends on) or you can analyse all dependants (which classes/packages depends on the currently selected class).

If you are analysing the dependencies, you can show the classes or packages, on which the specified class depends on. Furthermore, you will see all third-party libraries, on which the class depends on. If you do not want to see some specific packages, you can apply a filter (button “edit filter”), on which you can define excluded packages.

The generated graph looks like following. It is almost the same as the textual dependency view, with the exception, that no third-party libraries are shown.

This tool is user friendly. If you are using this tool, you will very fast get to work with it. I use this tool to find dependants on a class and to draw simple UML diagrams of a class (very useful if you want to draw a UML diagram from just one class with all it dependencies).

Today, I had the problem to iterate backwards in a ArrayList. Didn’t know, there is a ListIterator:

List<string> theList = new ArrayList<string>();
theList.add("a");
theList.add("b");
theList.add("c");
ListIterator<string> liter = theList.listIterator(theList.size());
while (liter.hasPrevious()) {
  System.out.println(liter.previous());
}

Generics are very useful. But sometimes, they don’t fullfil all required needs. Today, I had a small problem. Over the parameter of a method, a Class definition was passed. In the method, I had to cast an object of type Object into a concrete type (the concrete type was T, defined by Generics). The easiest way is to put the cast between a try and catch block. This will work, no question. But in my piece of code, a try and catch block wasn’t very nice. For this reason, I tried to check, if the object o is of the type clazz. Unfortunately, instanceof doesn’t work with dynamic defined classes. But there is a simple solution: just use the method isAssignableFrom.

private void test(Class<?> clazz) {
  // the Object o is from somewhere...
 
  if (o instanceof clazz) {
    // does not working
  }
 
  if (o.getClass().isAssignableFrom(clazz)) {
    // is working
  }
}

Today I stumbled upon a nice solution, to use the Collections.EMPTY_LIST with Generics. Just use the method emptyList with Generics instead of the constant value.

For example:

Collections.<string> emtpyList();

We use JiBX in our current project and had the problem, that JiBX won’t trim whitespaces automatically. For example, a XML tag like <test> asdf  </test> get’s stored as “ asdf  “ instead of “asdf”.

To solve this problem, we created an user-defined formatter for Strings.

package ch.stefanjaeger.formatter;
public class StringFormatter {
  public static String trimString(String untrimmed) {
    return untrimmed.trim();
  }
}

Now just update the binding file of JiBX and JiBX will trim whitespaces:

<format
deserializer="ch.stefanjaeger.formatter.StringFormatter.trimString"
type="java.lang.String" />

Are you a real men (or women)? Because if you are one, Eclipse offers you the possiblity to “don’t click” Try to use the simple shortcut CTRL + 3. What happens? Eclipse opens the Quick access window:

Now, type what you want, for example “new xml file”, and Eclipse searches for the command, which consists of these words:

Also very interesting is the access to the Preferences window. Try to search for “classpath variables” or “build path”, you get direct access to these settings. Also interesting is “Generate Getters”. If you don’t know a specific shortcut, just use CTRL + 3 from now on!

This is the last hint this week. While working with JiBX, I had the situation, that there were some null values in the Java class.

JiBXTestApplication
Exception in thread "main" org.jibx.runtime.JiBXException: null value for element
"{http://stefanjaeger.ch/CustomerSchema}city" from object of type ch.stefanjaeger.jibx.Customer
        at org.jibx.runtime.impl.MarshallingContext.element(MarshallingContext.java:713)
        at ch.admin.bit.edec.common.declaration.Versandvorgang.JiBX_binding_marshal_1_0(Unknown Source)
        at ch.admin.bit.edec.common.declaration.Deklaration.JiBX_binding_marshal_1_0(Unknown Source)
        at ch.admin.bit.edec.common.declaration.JiBX_bindingDeklaration_access.marshal()
        at ch.admin.bit.edec.common.declaration.Deklaration.marshal(Unknown Source)
        at org.jibx.runtime.impl.MarshallingContext.marshalRoot(MarshallingContext.java:1041)
        at org.jibx.runtime.impl.MarshallingContext.marshalDocument(MarshallingContext.java:1111)
        at ch.admin.bit.test.jibx.JiBXTestApplication.main(Unknown Source)

Per default, JiBX doesn’t allow null values. If there is a null value, it throws an JiBXException while marshalling.

To allow null values, you have to define explicit the attribute usage="optional" on a value or structure element in the binding file. If JiBX finds a null pointer on a member, JiBX does not fill an empty value to the xml element,  JiBX will skip the element.