The other day, I paid a visit to the guys at the ZFabrik just a few blocks from my office in Walldorf. I was intrigued by the rumours about their Z2 environment. After a one-hour joy ride with Z2 concepts I was no longer intrigued - I was impressed. So impressed that I want to share it with you - forgive the lack of detail, this is only a first impression (pun intended).
So what is it all about? They are trying to address some major weaknesses of server-side Java development:
- long development / deployment / debug cycles
- painful debug setup in case of problems at the customer's (I want to debug, now which release is the customer using, where can I find it in my source control system, how do I set up my workspace, has the customer modified any code)
While they are at it, they are tackling other issues as well:
- nightly builds may no longer be necessary
- inconsistent deployment states on a server are history
Sounds almost too good to be true, so what's their approach?
Z2 is a Java server which relies heavily on OpenSource projects and which runs special Z2 projects. These projects are more or less regular Java J2EE projects, but they follow certain proprietary structural conventions and are equipped with extra meta information.
Subversion is currently the only fully supported version control system.
The reason is SVN's quick top-down delta check, but SVN is not an integral part of Z2 (for fast prototyping, there is a file-based alternative and they are toying around with MIME-repository and GIT prototypes).
For a start, you set up your project and code in Eclipse similar to any other Java project. Z2 kicks in as soon as you want to run your code:
Instead of comiling and deploying your code, you tag it ('arm' it in Z2-speak) and ring the Z2 server (which needs to live on your development machine).
The Z2 server will read you project's meta data which tell him which other projects it needs. If it hasn't done it already, it will automatically download or update the corresponding binaries. It will then compile your code and use a nice trick: the compiler and the Z2 runtime share the same classloader.
So once the compilation is successful, the code is automatically 'deployed', i.e. the classes are immediately available to the server runtime.
Z2 will then do delta checks on the needed libraries, reload them if necessary and also restart your web application.
No more I/O to write class files, no more zipping, sending the stuff over the wire, unzipping and re-loading. It is done in one step.
If this reminds you of ABAP, it is no coincidence - have a look at the bio of the ZFabrik founders 😉
The Z2 server that you run during development is the same kind that will run at the customer's. Instead of ear-files, sca's or sda's you will deliver the sources to the customer's, Z2 will compile and run them. So just like with ABAP, the sources will always be instantly available and debuggable at the customer's.
Sounds like a supporter's dream.
So is there a catch? In fact, there are a few:
For a start, project structure and meta-information are proprietary. This means extra effort for the developer and it makes it hard to port existing projects.
But the same is true for other technologies such as NWDI.
Then you can no longer freely choose your target platform. You are limited by the capabilities of Z2. Currently, it is only half a J2EE container based on Jetty. You won't be able to run an OSGI project or an EJB 3.0 project. This may change in the future, but the server needs to be adapted for each and every technology you might want to use.
Also, there is no standard answer yet how a patch will be delivered to the customer. You would still need to establish a channel or transport system for your sources.
All summarized, I find Z2's approach extremely promising and innovative.
Anyone who has wasted hours and hours deploying code to a J2EE engine will instantly see the benefit of Z2. However, in order to become an industry-strength product it would still require some honing.
