With Java EE 6 and GlassFish v3 out, it is time to take a little break and look at the application server world. J2EE 1.2 was created in 1999, that’s 10 years ago. The application server market at the time was completely different of the one today. There was Weblogic and Websphere, other proprietary application servers (not following J2EE) and no open source application server. Today, it is a completely different story.

The application servers’ world has changed so much in the last 10 years, but people still have in mind the heavyweight server that takes huge amount of RAM, disk space and takes ages to start (being completely useless for agile developers who need to test and code quickly and often). So let’s focus on some application servers  (Geronimo, GlassFish, JBoss, Jetty, JOnAS, Resin, Tomcat, Weblogic and Webspere) and check some parameters.

The benchmark

Disclaimer :This is not a real benchmark !

In this little test I’m just concerned about the usability of an application server for a developer. The idea is to download it, install it, start it and take some measurements (size of download, ease of installation, size of disk, startup time, size of RAM…). That’s all. No deployment of an application, no fancy twists to gain performance…. Because some of these application servers are resource consuming, I’m doing all my tests on a Windows XP virtual machine (running on Virtual Box 3.1). It is a fresh install of Windows XP sp3 with 1Gb of RAM and not too many software installed (I had to install Avast but). So when I boot there are 27 processes running and using 230 Mb of RAM (leaving 770 Mb free). Virtualizing can be slower, so keep in mind that startup time can be a bit faster that what I’m giving you here. I use JDK 1.6.0_17 (when it’s not bundled with the server). No optimization at all is made (I haven’t twisted the JVM, or antyhing application server parameter, everything comes out of the box).

To calculate the startup time, I don’t do any fancy rocket science either. I just start the server a few times, check how long it takes and use the best startup time. Also remember that some servers do not load any container at startup, making them very fast to start. Others load everything (making them slower). Again, I have to point out that I’m not deploying an application, so it’s really starting up the server from a fresh install. To calculate the memory footprint, I just use the Windows task manager and check the size of the java.exe process.

Disclaimer bis : Some of these servers were completely unknown for me, so I might not have been completely accurate. Feel free to leave a comment.

Disclaimer Ter : And again, this is not a real benchmark, so don’t use it to sale any product to your customer ;o) I just wanted to give an overview of most application servers and some numbers.

Geronimo

Geronimo is the Apache Java EE 5 application server.

Geronimo 2.x

Geronimo 2.x comes with two flavours : one bundle with Jetty, the other one with Tomcat (the one I’ve picked up).

(*) user : system / pwd : manager

GlassFish

GlassFish is the open source reference implementation of the last Java EE specifications.

GlassFish 2.x

GlassFish v2 is the reference implementation of Java EE 5.

GlassFish 3.x

GlassFish v3 is the reference implementation of Java EE 6.

JBoss

JBoss is the RedHat open source application server.

JBoss 5.x

JBoss 5 is a Java EE 5 application server

(*) That’s using the default domain

JBoss 6.x

JBoss is still a work in progress. It will eventually implement Java EE 6.

Jetty

Jetty provides an HTTP server, HTTP client, and a Servlet container.

Jetty 6.x

Jetty 7.x

JOnAS

JOnAS is an application server part of the OW2 development community.

JOnAS 5.1.1

Resin

Resin provides an HTTP server, HTTP client, and a javax.servlet 2.5 container.

Resin 3.x

Resin 4.x

Resim 4.x is still in development. It implements the Java EE 6 Web Profile.

Tomcat

Apache Tomcat is an open source software implementation of the Servlet specification. So we can say it’s a web container that servers Servlets and JSPs.

Tomcat 6.x

(*) To be able to log on to the admin console, you need to change the %TOMCAT_HOME%\conf\tomcat-users.xml configuration files and add a manager role.

Weblogic

Oracle Weblogic server belonged once to BEA and is a Java EE 5 application server.

Weblogic 10.x

Websphere

Websphere 7.x

Websphere 7 is the Java EE 5 application server of IBM.

Conclusion

There is not a real conclusion that you can take out of these tests, just some hints and numbers to show you that things are moving. Comparing Websphere with Tomcat is like comparing apples with bananas. Of course Tomcat is way faster and lighter than Websphere, but it doesn’t do the same thing. Also some application servers are minimalist and only come with application containers. On the other hand, other come with integrated portals and so on. So, of course, the startup time is different.

All that to say that the figures of the table below have to be taken with respect of what the application server does (remember that Tomcat and Jetty are just servlet containers). In red the less efficient, in orange the second less efficient, in green the most efficient, in blue the second most efficient.

Java EE 5

If you only concentrate on the Java EE 5 implementation, you’ll get the sub-table below :

When you read this table there are things that you would have not expected. For example, JBoss is the slowest server to startup and Weblogic is the fastest. JBoss is also the one that has the biggest memory footprint. Websphere has the second less efficient score of all categories, while GlassFish has the second most efficient scores. JOnAS, on the other hand, has the smallest memory footprint.

Again, I haven’t deployed any application, used the administration console extensively, created clusters and did any fancy performance tests. But I wanted to show you that a full Java EE 5 server can start in 9 seconds or can only take 73 Mb or RAM. With Java EE 6 coming and the Web Profile, application servers have to become more modular and carry less weight. GlassFish v3 is a good example as it starts up in only 5.6 seconds and Resin 4 in 1640 ms. Application servers today are not the same that when they were created 10 years ago. Things have changed : Java EE 6 has become lighter, and so are the application servers.

PS : If I have omitted an application server that you (and I) think is important, let me know and I’ll give it a try and add it to the list. If you have any information to report, feel free to leave a comment.

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.