If you don’t already know it, next week is Devoxx : the biggest European Java conference. It’s my 4th time there and this year I’ll be doing 2 conferences, 1 BOF and 1 book signing session.

• Tuesday, from 9:30 to 12:30 : University talk The Java EE 6 Platform.  I’ll be doing a 3 hours talk with Alexis Moussine-Pouchkine with plenty of demos. We will gradually develop a web application using most of the EE specifications (Managed Bean 1.0, JPA 2.0, Servlet 3.0, EJB 3.1, JSF 2.0, Bean Validation 1.0 and JAX-RS 1.1)
• Tuesday, from 7pm to 8pm : BOF Why Should I Care About Java EE 6 ?. If you’ve attended the university talk or if you just want to talk about Java EE 6, come to this BOF. With Alexis we will be sharing this BOF with Paul Sandoz, Roberto Chinnici, Ludovic Champenois and Emmanuel Bernard.
• Wednesday, from 3:10 to 4:10 : Conference talk What’s new in Java EE 6 ?. This one hour talk is for people who already know Java EE 5 and want to discover what’s new in EE 6. I’m proud to say that I’ll be talking in room number 8 (the biggest) just after James Gosling. Cool !
• Wednesday, from 4:10 to 4:40 : Book signing session. If you want to know more about Java EE 6 and get a copy of your book signed, let’s meet in the ground floor at the book store.

And because Devoxx is full of things to do, Tuesday night is the speakers’ diner (that’s always nice), Wednesday the JUG Leaders’ BOF (with James Gosling as a guest star) and Thursday, with my friends Emmanuel Bernard, Guillaume Laforge and some specials guests, we will record our famous Cast Codeurs podcast.

And, of course, Devoxx is mostly about meeting people and attend conferences. See you there.

Sometimes you just want to map a list of primitive types. For example, a Book has a list of tags and tags are just strings. So you want to do the following :

@Entity
public class Book {

  @Id
  @GeneratedValue
  private Long id;
  private String title;
  private Float price;
  private String description;
  private String isbn;
  private Integer nbOfPage;
  private List<String> tags = new ArrayList<String>();
  ...
}

What happens when you do this with JPA 1.0 ? The List implements serializable so the entire List object gets serialized into a blob column. What are the other choices ? Well, because JPA maps entities, you can create a Tag entity (with an ID and a value) and have a list of tags :

@Entity
public class Book {

  @Id
  @GeneratedValue
  private Long id;
  ...
  private List<Tag> tags = new ArrayList<Tag>();
  ...
}

@Entity
public class Tag{

  @Id
  @GeneratedValue
  private Long id;
  private String value;
  ...
}

That’s a shame to create a seperate entity when what you want is just a String. Now with JPA 2.0 you can use the @ElementCollection annotation on a list :

@Entity
public class Book {

  @Id
  @GeneratedValue
  private Long id;
  ...
  @ElementCollection
  @CollectionTable(name ="tags")
  private List<String> tags = new ArrayList<String>();
  ...
}

The @ElementCollection annotation will automatically map the list of strings into a table named BOOK_TAGS (<name of the entity>_<name of the attribute>). If you need to change the table’s name, just use the @CollectionTable annotation. The result is shown on the figure. The Book table contains all the Book attributes, and the TAGS table contains the BOOK_ID foreign key and the value of the tags.

If you then want to find all the books that have the tag ’scifi’, you can just write the following JPQL query :

SELECT b FROM Book b WHERE b.tags = ’scifi’

Download the code of this example. It uses EclipseLink 2.0-M9 and the Derby database.

Sometimes you write a blog to express an idea, to ask some feedback from the community, to share a very nice trick… or because you always forget something and want to write it down so you can remember later on. That’s the reason of this post. I never remember how to use the maven-ear-plugin, so I’m writing it down. There is something funny with Maven and I. I spend hours trying to figure out to do something with Maven, and then, I automatically forget it. That’s the beauty of human’s brain : it doesn’t hold junk information for long.

Let’s say you have a project made of a Web module, an EJB module and external Lucene libraries. You then need to package this entire application into a ear file plus a few configuration files (login-config.xml and the application.xml deployment descriptor). With Maven each module is defined into a separate directory with its own pom.xml. So you will end up with the following structure :

• a root pom.xml
• a web module with its own pom.xml
• an EJB module with its own pom.xml
• an ear module that will be used only to package the entire application

I will not define what’s in the pom.xml of the web and EJB module, but only the interesting part : the pom.xml of the ear module, that’s where you define the maven-ear-plugin :

• The first part of the pom.xml is quite normal, nothing special except the packaging that is set to ear (<packaging>ear<packaging>).
• Then you have the dependencies. Here you define the web and EJB modules as well as the Lucene libraries. Note that it’s very important to specify <type>war</type> for the web module. If you don’t Maven will look for a jar file.
• Then comes the definition and configuration of the maven-ear-plugin. Notice that I redefine the artifacts that depend on the application but I add the extra information of the module : <webModule>, <ejbModule> or <jarModule>. Also note that I’ve decided to package the Lucene libraries into a subdirectory called lucenelib.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.example.mvnearplg</groupId>
  <artifactId>ear</artifactId>
  <packaging>ear</packaging>
  <version>1.0</version>

  <parent>
    <groupId>org.example</groupId>
    <artifactId>mvnearplg</artifactId>
    <version>1.0</version>
  </parent>

  <dependencies>
    <!-- web and ejb modules -->
    <dependency>
      <groupId>org.example.mvnearplg</groupId>
      <artifactId>ejb</artifactId>
      <version>1.0</version>
      <type>ejb</type>
    </dependency>
    <dependency>
      <groupId>org.example.mvnearplg</groupId>
      <artifactId>web</artifactId>
      <version>1.0</version>
      <type>war</type>
    </dependency>
    <!-- external lucene libraries -->
    <dependency>
      <groupId>org.apache.lucene</groupId>
      <artifactId>lucene-highlighter</artifactId>
      <version>2.4.1</version>
    </dependency>
    <dependency>
      <groupId>org.apache.lucene</groupId>
      <artifactId>lucene-core</artifactId>
      <version>2.4.1</version>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-ear-plugin</artifactId>
        <version>2.3.2</version>
        <!-- configuring the ear plugin -->
        <configuration>
          <modules>
            <webModule>
              <groupId>org.example.mvnearplg</groupId>
              <artifactId>web</artifactId>
            </webModule>
            <ejbModule>
              <groupId>org.example.mvnearplg</groupId>
              <artifactId>ejb</artifactId>
            </ejbModule>
            <!--extra lucene libs into lucenelib directory -->
            <jarModule>
              <groupId>org.apache.lucene</groupId>
              <artifactId>lucene-highlighter</artifactId>
              <bundleDir>lucenlib</bundleDir>
            </jarModule>
            <jarModule>
              <groupId>org.apache.lucene</groupId>
              <artifactId>lucene-core</artifactId>
              <bundleDir>lucenelib</bundleDir>
            </jarModule>
          </modules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

The ear plugin looks for its resources under the src/main/application directory. That’s where you typically put your META-INF directory with the application.xml file and some extra descriptors. So the result is that :

• The external Lucene libraries are under the lucenelib directory (that’s because I’ve specified the <bundleDir>, otherwise they would have been under the root directory)
• The META-INF/application.xml and the /login-config.xml files are automatically packaged in the ear file (that’s because they were under the default resource directory src/main/application).
• The ejb module (ejb-1.0.jar) and web module (web-1.0.war) are located under the root directory

Next time I’ll need the ear plugin I’ll remember to read my own post.

One beauty of living in a country with nearly 20 Java User Groups is that you can travel around while talking about your favourite topics. For me, at the moment, it’s Java EE 6 (thanks to my book). So last week I was invited to the Riviera JUG to give a talk about the new features of EE 6. As you can see on the photo below, even if it was a sunny day by the beach, nearly 90 people turned up.

Unfortunately I didn’t have much time to profit from the beach of Nice. Well, guess what ? On Thursday I’ll be talking at the Bordeaux JUG (and thus having some red wine during the talk) which celebrates its first anniversary. And the week after, at the Lyon JUG giving a talk on the same topic. November I will concentrate on Devoxx where I’ll be doing a 3 hours university talk with Alexis Moussine-Pouchkine and a one hour conference talk. And back to French JUGs on the 7th of December at the Breizh JUG for a Java Ee 6 presentation.

I’ll finish this year back to my home town JUG. I’m glad to announce that with Michaël Isvy we’ll be doing a Java EE 6 vs Spring 3.0 talk at the Paris JUG on the 8th of december.

A busy EE 6 year and I already have plans to tour other French JUGs in 2010.

As we all know, the percentage of IT projects that succeed is very low, and this post doesn’t have the pretension to explain you why. The reasons are multiple and complex. But there is one that we all know about and live on our day to day jobs : IT projects are mostly made of junior developers and tons of unexperienced managers. Well, at least in France, but I know other countries that follow the same pattern. Here, code is bad. So if you turn 30 and you are still spending 8 hours a day in front of your IDE it’s because there’s something wrong with you. And, of course, your salary will not increase as development is not seen as a valuable job. So, what do you need to do ? Become a project manager of course. You will get a pay rise… and a gorgeous girlfriend. What ? You don’t believe me ?

The other day I went to a IT university (I’m not mentioning the name here) and this is what I could see on the walls :

This one says “pssst… become a project leader”. As you can see on the right side, the guy wears a nice tie and his girlfriend looks gorgeous.

This one is better. On the left side is the developer’s girlfriend and on the right side the manager’s one (“become project manager“). I suppose I don’t have to explain this one.

This one says “Your are the one. You have already made your choice. Become a project leader”. That reminds you the Matrix of course. So the developer takes the blue pill and the manager the red pill.

I hope these ads haven’t been made by the teachers themselves but by the students. One way or the other, this is what your are taught at university. So when you are 22/24 years old and you start your first job, you definitely want to pull the nice girls and try to avoid coding as much as you can. 2 years of developing is enough, and when you turn 24/26, you want to manage projects… and fail miserably but you have the money and the gorgeous cheek.

As I said, this is not the only reason why projects fail, but it’s one of them. IT industry is one of the few where experience is not rewarded. An experienced lawyer is, an experience accountant also, but a developer should not be more than 30. This is clearly wrong and ads like these ones do not help in solving this cultural problem.

And what about you ? Would you prefer to become a project manager and have a nice girlfriend ?

A few weeks ago, Alexis Moussine-Pouchkine asked me for an interview. My book has been out for a couple of month now, Java EE 6 is getting hot, GlassFish V3 is closed to final, the Paris JUG is doing well, I’ve recently been nominated Java Champion, JSR 299 and 330 are working hand in hand, the Cast Codeurs podcast is a success, summer and vacations are on their way… it was time to have a break, a nice lunch with Alexis, a few glasses of wine, and have a chat.

So if you want to know a little bit more about all that, you can listen to the podcast or/and read the transcription of it.

GlassFish Podcast

Podcast transcription

Thanks Alexis

Yes, I am a Java champion my friends, and I’ll keep on Javaing till the end.

Do you know the Java Champion program ? It was created by Sun to recognize leaders in the Java developer community. The concept is to build an informal but select group of passionate Java technology and community people outside of Sun. As quoted in the Java Champions web site, these people can be :

• Java Luminaries; senior developers; architects; consultants; JCP members; etc
• Academics/University Professors
• Authors of Java-related content (online & print) and industry conference speakers
• Community leaders: Java User Group (JUG) Leaders and the Leaders of online Java portals

So as you can see, the Champions program is aimed at community. And the duty of a champion should be :

Java Champions would be in a Leadership role.  Champions would focus what they learn from the program back to the java community, spread the knowledge, and positively influence other developers. Steer people to the Java Community for technology problem solving, application development, or just plain “evangelization” of what Java can do.

So, how did I suddenly become a Champion ? First of all it is not sudden. Champions need to recommend people to become champion. Then, there is a vote within the Champion mailing list and you get voted in or not depending on the result. Last year, Vincent Brabant introduced me to the Champions community, but some members thought it was a bit to soon. I had to show my involvement in the newly created Paris JUG. A year later, Stephan Janssen asked a new vote, and I got accepted.

Why me ? Well, to become a Champion you need to fulfil at least 3 of the 5 principles, and these are the principle that I filled :

Principle #1: – Java Champions are Leaders. This is due to my involvement in the Paris JUG.

Principle #2: – Java Champions are Luminaries in their field. This is mostly due to the work I’ve been doing with the JCP with Java EE 6 (expert member on JSR-316, 317, 318).

Principle #5: – Java Champions are able to Evangelize or influence other developers through their own professional activities. And this one is related to the courses I’ve been teaching at the Parisian CNAM university, the two books I wrote (Java EE 5 and Java EE 6), the talks I give at conferences and JUGs, and recently the french podcast Les CastCodeurs.

It is an honour to be part of the Java Champions and I would like to thank them all for voting me in. Particularly Vincent Brabant and Stephan Janssen who proposed my nomination and Aaron who supervises the program. It’s been great to be part of Java, part of the community, part of the JUG Leaders and now be part of the Champions.

I will keep on the hard work and fill my role of a champion.

Up to Derby 10.4.2.0, the in-memory database mode wasn’t a real one because data was stored into files onto your disk. The new 10.5.1.1 supports a real in-memory mode were data is only stored in memory, with no files being created. As stated in the new features page : Initial implementation of a storage engine for Derby where all data is kept in memory. There is no documentation for this feature. This functionality itself is not yet fully implemented, but users are welcome to experiment with it. So I did test it.

First of all, if you are using Maven, you will be disappointed to know that the 10.5.1.1 release is not in the default Apache repository. You need to add the following repository to your pom.xml :

<repository>
  <id>Apache Repo</id>
  <name>Apache repository for Derby 10.5.1.1</name>
  <url>http://people.apache.org/repo/m1-ibiblio-rsync-repository</url>
  <layout>legacy</layout>
</repository>

Then, the JDBC URL has to be changed from jdbc:derby:chapter02DB;create=true to jdbc:derby:memory:chapter02DB;create=true.

As a little benchmark, I have an application with 25 test cases using in-memory storage with Derby 10.4.2.0. It took 5 minutes and 53 seconds to run all the tests. With the new 10.5.1.1 it only took 21 seconds. Not bad.

As you might know with JPA, the META-INF/persistence.xml file defines a persistence unit with some provider’s properties. For example, if you are using JPA in a Java SE environment, you will have to define the JDBC driver, database connexion (user and password), database URL and so forth. In JPA 1.0 these properties were not standard, so for each persistence provider you would have to use proprietary properties. For example, with EclipseLink this is what you would need to connect to a Derby database :

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
  <persistence-unit name="chapter02PU" transaction-type="RESOURCE_LOCAL">
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    <class>com.apress.javaee6.chapter02.Book</class>
    <properties>
      <property name="eclipselink.target-database" value="DERBY"/>
      <property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
      <property name="eclipselink.jdbc.driver" value="org.apache.derby.jdbc.ClientDriver"/>
      <property name="eclipselink.jdbc.url" value="jdbc:derby://localhost:1527/chapter02DB;create=true"/>
      <property name="eclipselink.jdbc.user" value="APP"/>
      <property name="eclipselink.jdbc.password" value="APP"/>
    </properties>
  </persistence-unit>
</persistence>

As you can see, each property is called eclipselink.something. With the new JPA 2.0 shipping with Java EE 6 in September, some properties have been standardised :

• javax.persistence.jdbc.driver — fully qualified name of the driver class

• javax.persistence.jdbc.url — driver-specific URL

• javax.persistence.jdbc.user — username used by database connection

• javax.persistence.jdbc.password — password for database connection validation

If you use the latest build of EclipseLink (reference implementation of JPA 2.0) you will be able to use these properties as follow :

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">

  <persistence-unit name="chapter02PU" transaction-type="RESOURCE_LOCAL">
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    <class>com.apress.javaee6.chapter02.Book</class>
    <properties>
      <property name="eclipselink.target-database" value="DERBY"/>
      <property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
      <property name="javax.persistence.jdbc.driver" value="org.apache.derby.jdbc.ClientDriver"/>
      <property name="javax.persistence.jdbc.url" value="jdbc:derby://localhost:1527/chapter02DB;create=true"/>
      <property name="javax.persistence.jdbc.user" value="APP"/>
      <property name="javax.persistence.jdbc.password" value="APP"/>
    </properties>
  </persistence-unit>
</persistence>

Except for the target-database and ddl-generation properties, the rest of the persistence.xml file is portable across implementations. Again, this is just an example showing how Java EE 6 is trying to make code as portable as possible. If you want to know more about it, check the JPA 2.0 specification.

Maybe like me you are used to read architecture documents that state that an application should have high availability. It’s not uncommon to read that an application should have four-nine availability (99,99%). But what does it really mean ? In the JBoss in Action book there is a very clear explanation by giving the allowed downtime per year. Here is the table :

3.1 seconds downtime per year, it’s really not a lot. So if you sign a contract with 99.99999% availability, make sure you have good lawers around you.