Four years ago, WAS Liberty was little more than a kernel, a web container, and a twinkle in an architect’s eye. Even at the time, it had a lot going for it. The web container was the bulletproof web container that powered its bigger sibling, WebSphere Application Server. The kernel was all-new, and it was rockingly good. Built using OSGi services, it was super-fast and astonishingly dynamic.

At the time, the model for application servers was that they did what they did – nothing more, and nothing less. They had a reputation as big, unwieldy pieces of software, packing more programming models than anyone could possibly need.

A different kind of application server

Liberty was different. It only loaded the features that were needed – if the requirements changed, features could be loaded and unloaded without a restart. The first time I demoed Liberty to one of our executives, I was all excited to show him how fast the server could start (3 seconds!). Then I realised that I couldn’t actually come up with any plausible demo script that required a restart, because the server coped with every possible config change (including support for whole specifications) dynamically.

Liberty on all the hardware

Liberty had a small download size, and a simple extract installation. We could give it away on USB sticks (which was exciting) and run it on a Raspberry Pi (which was very exciting). We went a little bit crazy finding all the hardware that could run Liberty. (Simon’s Raspberry Pi – check. Alasdair’s tablet – check. Tom’s old smartphone – check.) We took the server and embedded it a bunch of mad environments. (Server-in-hat – check. Running in, and driving, a model car – check. Embedded in a cuddly throwable ball – check.)





All grown-up now

Liberty’s all grown up now. You can still run it in a hat but, as of June 26th 2015, you’re running a fully spec-compliant Java EE 7 server in a hat. I remember writing the first version of the JPA support, three and a half years ago. I was pretty pleased with what I did (especially as my first step was learning JPA), but it was definitely a beta, and there were an awful lot of limitations. Those limitations are well and truly gone now.

Zero migration

One unique thing about Liberty is that it’s able to move forward without leaving things behind. Liberty supports JPA 2.1 now, but it also still has the JPA 2.0 support I started. More generally, it supports Java EE 7, but it also supports many of the Java EE 6 specifications.

If you update the application server, your applications will keep working (we call this zero migration). The server configuration controls which version of a feature (or specification) you’re using. To move up a level, you change the server config. Separating the server version changes from the application behaviour changes makes Liberty able to support a huge range of heterogeneous workloads. It also makes upgrading a lot less daunting for an ops team.

Liberty FTW!

Our intention was to make an application server that was a joy to develop applications on. I think we’ve succeeded, and the development team got something out of it, too – we ended up with an application server that was a joy to develop. Thanks for everything, Liberty!