Trying Liberty 8.5.5

Historically Java EE servers were known for being monolithic and heavyweight.

Over the years this has improved tremendously with many free, open source and lightweight solutions available, such as GlassFish, TomEE, Resin and JBoss. Even the grandfather of the modern Application Server, Bea's WebLogic (now Oracle's) has severely slimmed down.

One "heavyweight beast" remained though; IBM's WebSphere. It's perhaps an understatement to say WebSphere is not universally liked by developers. A 2GB download size that happens via a proprietary installer (which is 100MB), which doesn't cleanly work on all possible Linux flavors and doesn't work at all on OS X, which needs another 200MB orso just to create a "profile" after the 2GB download which came after the 100MB installer, takes ages to start and can't be started in any of the popular IDEs (like Eclipse, NetBeans or IntelliJ) are all things that don't really fly with the average developer. Operations or system admins may have another view on this, but for a developer things like this just make a product less attractive.

So what do developers actually expect?

After some research it appears the following is sort of the expected list for Java EE servers. Any product deviating too much from it will most likely experience a lot of heat from the developer community. The list:

1. Server can be downloaded from an easy to find, public (no-login) download page
2. Download is a relatively small archive (no binary installer, total size should not be more than 200MB)
3. After archive is unpacked, there should be no script or commands that need to be executed manually (e.g. to setup things like "servers", "realms", "users", etc)
4. Server can be directly started from popular IDEs using an easy installable and free plugin (e.g. via Eclipse's Marketplace) by just pointing to the installed directory and hit a "start server" button
5. Server should work on all popular desktop operating systems (Linux, OS X, Windows) without needing a "special" Java version
6. Server basic startup time (without any applications deployed) should be a few seconds at most on modern hardware
7. Supports the Java EE Full- or Web Profile out of the box

For the somewhat more advanced developers, the following is important too:

1. Server is either open-source, or source is available (shared source)
2. There is a publicly available bug tracker (e.g. JIRA)
3. There is a publicly available source code repository

Ticking off items on the above list, we see that the older WebSphere versions (pre version 8) failed on nearly every point. It supported the Java EE full profile and there is something of a bug tracker available, but that's about it. IBM must have realized its server was not the most popular product in the general developer community. With WebSphere 8 running from a normal IDE like Eclipse was officially supported, taking a very real pain point away. However, all the other points remained open.

In a for some perhaps surprising move, IBM has recently(*) introduced a new Java EE application server called Liberty that focusses completely on being lightweight and friendly to developers. *) Liberty has actually been available for over a year, but wasn't an official Java EE server before, it now is.

In this article we take a quick look at Liberty to see how it holds up against The List™.

1. "Server can be downloaded from an easy to find, public (no-login) download page"

Liberty 8.5.5 can be downloaded from ibmdw.net/wasdev/downloads/websphere-application-server-liberty-profile. The page is easy to find, public and doesn't require a login. Check! 10 points for Liberty here!

2. "Download is a relatively small archive"

The archive that's downloaded in the previous step is a self-extracting jar file called wlp-developers-runtime-8.5.5.0.jar and weighs in at a super reasonable 52.7MB. For a pure Web Profile implementation it's a bit large, but when realizing that Liberty actually implements a little more than just the Web Profile (like e.g. JMS) this is a really good download size.

Purists may argue that a self-extracting archive that you extract with java -jar isn't really an archive. While this may indeed be an important point for some, for the average developer typing java -jar archive.jar vs tar -xzvf archive.tgz doesn't make a whole lot of difference. Still, because of this tiny, tiny issue Liberty gets a 9.5 here. (interesting to note is perhaps that the Oracle JDK also went from a self-extracting archive to a 'regular' archive with JDK 7)

3. "After archive is unpacked, there should be no script or commands that need to be executed manually"

After the archive was unpacked via java -jar, it was a simple directory in the location where I typed the command. No extra setup "nonsense" was needed. Again, a full 10 points for Liberty here.

4. "Server can be directly started from popular IDEs using an easy installable and free plugin"

Using Eclipse 4.2 (Juno) I went to the Eclipse Marketplace and searched for "Liberty". Installation was straightforward (I did have to de-select some "extra tooling" as I just wanted the WTP adapter, but this needs to be done for nearly every other AS out there). After that I could create a new WTP server using the normal new - server command in the Servers view, which in a very straightforward and standard way asked me for the directory where I unpacked Liberty. After that, just hitting Start on the new entry in this same Servers view was enough to start it. No weird and unwanted proprietary toolbars or icons etc were installed.

There was however one peculiar thing to be done here. For some reason Liberty is by default statically configured to support JSP only and it wants you to explicitly say that its a Web Profile implementation. In order to do this, you have to unfold the "WebSphere Application Server V8.5 Liberty Profile" node in the mentioned Servers view, then double click on the "Server Configuration" node, then click on the "Feature Manager", then in the Feature Manager node click on the "Add..." button and from the dialog select "webProfile-6.0".

This entire sequence of actions seems a bit unnecessary to me. I certainly haven't seen any other application server requiring it and it throws the developer back into the world of mandatory having to configure things, instead of the modern download, unzip, deploy, run cycle that has become the default.

While up till now Liberty was doing really well, and the plug-in installation went really well too, Liberty somewhat drops the ball here. Perhaps this is a remainder of the old WebSphere server where everything had to be configured first, or perhaps there's an issue with dynamic modularity. Whatever the underlying reason, the developer is inescapably confronted with this, and it's a step that none of the other servers require. Because of this Liberty gets only 6 points here.

5. "Server should work on all popular desktop operating systems"

For some reason or the other, the old WebSphere server cannot be run on OS X. There's no OS X installer, and the required IBM JDK is not available for OS X either.

No such worries with Liberty. It doesn't require any special JDK, and runs perfectly fine on OS X. Liberty gets the full 10 points here again.

6. "Server basic startup time (without any applications deployed) should be a few seconds"

A cold start (non-debug) without any applications deployed took approximately 2.6 seconds on my 2.93Ghz i7 machine with SSD (did several runs and the time was quite consistent). This time is rather good, although not as good as JBoss EAP 6.1 which takes 1.8 seconds on the same machine for a cold start without any applications deployed. Deploying a simple application (A Servlet, a Filter, a JSF ViewScoped bean and a Facelet) was near instant (0.25 seconds), but there was a noticeable delay when the Servlet was first accessed. The Servlet itself was completely empty (having an empty get method and no init method). When this first access took place, some initialization messages appeared in the log with a total time span of 0.5 seconds.

When accessing the Facelet there was again a small but noticeable delay. From the log it appeared that although Liberty did some JSF initialization when the first (non-JSF) servlet was accessed, it didn't initialize the FacesServlet. When the first Facelet (.xhtml file) was accessed, it did do this initialization. After this first access, response times were as fast as can be.

Clearly Liberty does a lot of lazy loading and initialization, which is good and done by many servers. Liberty seems to defer more work to when something is actually requested as opposed to other servers which seem to be doing more on deployment time. One thing that is peculiar when working from Eclipse is that in the Eclipse Console only a subset of the log messages are displayed. The tooling creates a project in the workspace though (kinda like the Tomcat WTP adapter does as well) and from there the full log can be found under servers - defaultServer - logs - messages.log. This is a bit unusual.

All in all Liberty does really well here. The performance characteristics are slightly different from other servers with respect to lazy loading, so an exact comparison would need some effort. For average development tasks it indeed starts up within a few seconds, so that's the full 10 points for Liberty here.

7. "Supports the Java EE Full- or Web Profile out of the box"

Liberty supports the Java EE 6 Web Profile and some additional features from the full profile like JMS. It basically supports this out of the box (no additional downloads required), but as mentioned above it does needs to be configured for the Web Profile. Points have already been deducted for that since it breaks the easy install and run of the plug-in, but because of this issue it's difficult to give Liberty full points here. Yes, it does support the Web Profile which is really good, but it doesn't do it exactly out of the box. Difficult... but let's give Liberty 9 points here.

The source code

Looking at the list for the more advanced developers, we can keep it short here. Liberty is not open-source and as far as I know there's no option to obtain the source for evaluation or debugging. There is some defect tracking online though (which e.g. WebLogic doesn't seem to have), but it's not an easy to browse Jira instance. Not having the source code can be really troublesome in some situations. For instance, we got a bug report for OmniFaces which concerned WebSphere and Liberty. Investigating what exactly happens has proven to be quite doable on JBoss and GlassFish etc where we could attach the source and just *see* what happens. With Liberty being a black box all we can really do is deduce behavior from experiments, which is much more time consuming. The only thing going for Liberty here is that it does have a very, very detailed trace logging, but this too is not a replacement for just having the source and the ability to put break points at critical places.

Miscellaneous stuff

One issue that I encountered when evaluating Liberty was that it's bundled with a very old JSF implementation, namely MyFaces 2.0.5(*) which is from April 2011 and thus over 2 years old. In the meantime Myfaces has fixed many important bugs and greatly improved its performance. Although none of the application servers ever come with the very latest implementation of its dependencies, IBM is pushing things here to its limit. Extra problematic is that it's not just MyFaces 2.0.5, but a special modified version. It's not easy and without consequence to update this to a newer version. *) According to the official certification page Liberty uses an even older version, MyFaces 2.0.4. This seems more likely as proprietary options that were introduced with MyFaces 2.0.5 can't be found in the Liberty bundled version.

Another small issue I found with Liberty is its naming. Liberty itself is a perfect name, but IBM doesn't use it exclusively and seems torn between the name for its other offering (WebSphere) and this new name.

For instance the archive I downloaded was called "wlp-developers-runtime-8.5.5.0.jar", where I would have expected something like "liberty-8.5.5.jar". Something like this happened after installing the Eclipse plug-in as well; the default name of the server runtime was "WebSphere Application Server V8.5 Liberty Profile". Personally I think the "Profile" suffix doesn't add anything and is only confusing with respect to the term "Web Profile". As a brand new server, IBM might have more success just calling it "Liberty" and giving it its own version number. E.g. Liberty 1.0, or IBM Liberty 1.0 etc. It looks like the community is already using names like this anyway. Many people I spoke to indeed refer to it as just "Liberty". The idea of Liberty being merely a profile of the "not universally liked" WebSphere doesn't seem to particularly resonate with the developer community.

Rounding up we've seen that Liberty does really well for developers. There are a few minor issues, but nothing really big. This is a completely different experience than the one IBM gave developers with the older WebSphere offerings.

Further reading:

1. 2013/03 Taking the WebSphere Liberty Profile for a spin, using Intellij on the iMac
2. 2013/04 The Great Java Application Server Debate: IBM Liberty Profile (reviews the older, non-Java EE compliant Liberty)

Arjan Tijms