Skip to Content

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.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Ethan Jewett
    Hi Jens,

    Sounds interesting, but can you talk a little bit more about the pain-points this is addressing?

    To me, this sounds a lot like Maven and almost exactly like SBT (which is Scala-only I believe). Except that whereas Maven and SBT turn out standard artifacts that can be exported to any Java application server, Z2 creates proprietary artifacts that can only be deployed to a Z2 server.

    There must be something I’m missing here. What is the pain-point this is addressing that standard tools miss?


  2. Priya Ranjan
    Nothing new here. A version control system like SVN, mercurial or git and a build system like Hudson, Maven or Gradle will do exactly all of this. Atlassian or Sonatype provide end to end solutions for such problem including issue tracker and project management.
    1. Jens Steckhan Post author
      Z2’s innovation is not about using a source control system or having a build environment in place.

      In any other Java environment, it is necessary to do a separate deploy step once you have locally built your sources. And this deploy step is usually quite time consuming.

      This is not the case with Z2, since they are doing without a separate deployment: it is one integrated step with no I/O and a shared class-loader. I don’t see how any of the technologies that you have mentioned would address this?

  3. Henning Blohm
    Being one of the developers of z2, a few notes:

    Z2 is not a build tool, i.e. its purpose is not to turn project descriptions and code into some binary artifact that can be deployed on some application server.

    Instead it is a a runtime that keeps itself in sync with definitions stored in a repository like a subversion repository or a file system by consistently pulling stuff as required and – if needed – also compiling Java code.

    When developing with it, there is no need for a build tool or for a central CI infrastructure and redeployments to integrate as you automatically have a consistent state (which is kind of the point here). To set up a dev environment (and similarly a production node) you check out the z2 core of the solution and fire it up.

  4. Henning Blohm
    Being one of the developers of z2, a few notes:

    Z2 is not a build tool, i.e. its purpose is not to turn project descriptions and code into some binary artifact that can be deployed on some application server.

    Instead it is a a runtime that keeps itself in sync with definitions stored in a repository like a subversion repository or a file system by consistently pulling stuff as required and – if needed – also compiling Java code.

    When developing with it, there is no need for a build tool or for a central CI infrastructure and redeployments to integrate as you automatically have a consistent state. To set up a dev environment (and similarly a production node) you out the z2 core of the solution and fire it up.

  5. Matthew Harding
    Too often, we get hung up with only the tools and approaches we have available to us within the SAP domain, and blogs like this open our eyes to what is happening outside of the SAP world.
    Thanks for sharing,
    ps. For my 2 cents/opinion, release management processes in organisations that run SAP would likely not benefit greatly from this optimisation approach. i.e.  If they have NWDI working properly and have multi stage testing environments. Yeah – I know – There’s goes the agility and simplicity which is the whole point.
    1. Jens Steckhan Post author
      Let me put it in telegram style:
      performance, agility, no deployment, quick development cycle, complete environment at customers, little overhead.

      So they are promising more than NWDI ever did.
      And it looks as if they are truer to their word 😉

  6. James Geddes
    I confess that I’m not seeing the benefit of this at all. It looks like it’s not being positioned as a competitor to the NWDI, tools like Maven, or continuous integration environments. Instead, the purpose is to keep the binaries running on a particular server in sync with some collection of sources.

    What’s the benefit? While it might not look like you’re “deploying to a J2EE server”, you are — you’re just deploying your sources there, and the framework is compiling them. Furthermore, from a technological point of view, it doesn’t take a long time to deploy things to a J2EE server: even deploying to a big, enterprisey one like WebSphere or WebLogic takes seconds. It takes a long time to deploy to SAP’s J2EE server, but that’s a function of terrible source control/deployment products (the NWDI) and the human process of deployment (including approvals and propogation across a landscape), which won’t disappear no matter what technical solution you invent.

    The only benefit I can see is an ABAP-like situation where you can always have a look at the exact sources your binaries were compiled from. But any build tool worth its salt can already package sources to be delivered with binaries, and with a properly engineered and enforced deployment process, you can ensure that your build tool of choice is the only possible path to deployment, thereby guaranteeing that sources and binaries stay in sync.

    In contrast, the disadvantages are myriad and enormous, but they can easily be summed up: a break from standard Java tools and frameworks, and the Java community as a whole. It was precisely that philosophy (“we’ll use Java, but we’ll go it alone, invent all our own technologies, and break compatibility with existing frameworks”) that made SAP’s adoption of Java a catastrophe.

    Like Ethan, I’d like to know what problem this solution is meant to address.

    1. Jens Steckhan Post author
      Hi James,

      In a regular java system, you need wrapper projects to build – say – an sda with n class files, you write them to the file system, zip them, send them over the wire and unzip them again. With Z2, your delta sources are compiled and are immediately available for the server.

      So this would speed up the development cycle – I have spent a significant amount of time watching my machine deploy.
      True – I agree that other J2EE environments may be a faster than NWDI and CE; but Z2 is the most efficient approach I have seen so far.

      Regarding available sources: the difference between Z2’s approach and “any build tool worth its salt”: with Z2 you have the sources integrated in a source control system. With other tools you have them packed in a jar file.

      So I maintain my point: this could significantly speed up the development cycle and help with supporting problems at the customer’s.

      1. James Geddes
        Hi Jens

        Thanks for your response. Let me see if I’m following this. There are three parts to this system: an IDE (Eclipse with plugins), SVN, and a server (Jetty with some magic bits tacked on). I couldn’t quite follow the extent to which these things need to be on the same machine, but I’m going to assume none of them do. So, I write my code in Eclipse. Eclipse is actually compiling it all the time, so it’s debatable how much time I’m saving by not having to do it myself. Anyway, when I’m ready, I check my code into SVN. The server is aware of the checkin, does a delta, and compiles what it needs to. Presumably, this compilation has an output somewhere — that is, the class files are written somewhere. They’re then run in Jetty. Is my interpretation correct?

        Presumably, if I want to move this code between environments, I can move it to some production SVN repository, say, and the same thing happens.

        If I’m following correctly, I’m just not understanding how this is a timesaver. My classes are still being compiled. They are still being deployed. The only difference is that the compilation and hot deploy is being done from SVN by the framework instead of by the IDE. When last did you develop a web application using Jetty directly? Because that’s pretty blazing. I’m wondering if a lot of the timesaving here isn’t delivered by hot-deploying to a lightweight servlet container, and not by Z2.

        If I’m still way off track, maybe I’m just having a bad day. 🙂 It sounds like an interesting technical achievement one way or another.

        1. Henning Blohm
          Hi James and Jens,

          had a hard time getting through somehow. Seems like I lost some post and another one got posted twice :-(. Hope this doesn’t show up multiple times or the other ones magically reappear (apologies in advance!).

          Here are some pointers to more information:
          The life cycle and development approach is explained in some detail on the web site. An overview can be found here:

          Positioning w.r.t. Maven and classic ANT approaches is described here:

          @James: If at all then it does actually compete with NWDI. It is definitely geared towards solution development and maintenance.
          But it is all about the life cycle management approach. Application construction and APIs is just standard. There is no intention to teach people how to construct web apps in a new way. Even if you start using modularization features of z2 you will hardly get into a real lock-in situation. In the project I spend most of my time with these days we use the usual combination of Spring, Hibernate, Lucene, Quartz (and some more).


    2. Henning Blohm

      have to disagree here (disclaimer: I am one of the developers of z2).

      The main and the originally intended benefit is that system setup, distribution and maintenance, development is significantly lighter than with any alternative out there for Java. At some point in time the phrase “The Source is the System” sounded good to us. Saying it is supposed to bring a Script-Engine / ABAP style life cycle management approach to Java would most likely  raise an objection.

      The main distinction is that sources and (!) configuration is pulled from a repository (or your development workspace), rather than you pushing it onto the runtime. So the runtime is necessarily consistent with the state in the repository.

      As the whole system is defined in those repositories, setting up for production and development is just a core checkout and letting the pull begin.

      No build infrastructure needed to develop and integrate. No build infrastructure required to patch. Need a one-line fix. Just apply it.

      Wonder what changes have happened to the system? Check the repository (subversion) log. I am talking system here – not application!

      And no, it doesn’t break standards. The only thing it does not – intentionally – support is deployment by WAR archive and the like. Doesn’t make sense here.

      All application development interfaces e.g. for Web app development are completely standard (well jetty et al) – and of course not made by ZFabrik. No intention to tell you how to develop Web apps anyway.

      In the project I spent most of my time these days we use the usual suspects: Spring, Hibernate, Quartz and (actually) Vaadin.

      You can make use of modularization and configuration features that are (essentially) implied by the approach – but no must and hardly any lock-in.

      It does actually compete with NWDI (if anything). Much less than with Maven. Don’t want to go into details on that here (please have a look at this:

      And finally: This is not an SAP project. And it is available as OSS under ASL 2.



Leave a Reply