During JUDCon China 2012 Red Hat's Aleš Justin introduced Project CapeDwarf, a Google AppEngine API implemented with JBoss and other open source libraries. Sai Yang, Senior Planning Editor of InfoQ China, spoke with him about why he started the project, what challenges the project has faced, and his experiences as a software developer in general. This is a transcript of their conversation which was recorded in Beijing on the 29th November 2012.
InfoQ: Hi Aleš! Thanks for taking the time for our interview. So you joined Red Hat in 2006, and you worked on several projects around JBoss; can you briefly describe these projects? Like why did you start them, what structure they use, what technologies did you use?
Justin: I started doing the Microcontainer project with Adrian Brock and Scott Stark, which is the kernel of JBoss AS5 and JBoss AS6; and that was a lot of work for 2-3 guys. But it was also a good learning experience, working so closely with such really good developers. But then of course, every project comes to an end, you move on and don't really regret and look back, and I started working on Weld, which is a CDI RI [reference implementation].
I was always on the look out to do new stuff. So one of the things I also do is to work with Gavin King on Ceylon, which is a new language running on the JVM. I've known Gavin since I joined Red Hat, and I was quite keen when he talked about what he was doing. And one of the ideas behind Ceylon is to have a full platform with the language also being fully modular, and with its own runtime. With my kernel background, it was quite obvious what I can easily contribute to Ceylon - its runtime. I mean, the language itself and the compiler are both also very interesting - I've done something in that direction during my Mathematics studies - but I'm more into providing the runtime, making it modular and making the repositories play nicely within a modular environment in Ceylon.
So Weld, Ceylon, and then CapeDwarf. The whole idea behind CapeDwarf started with that Android was really getting popular, and then there is CDI and the Google App Engine.
So I was like, "Oh why not combine all those things - Android on the client, CDI and Google App Engine on the server side". At the beginning, implementation was quite different. Initially I wrote CapeDwarf Green - which is an adaptor layer for GAE and JEE APIs. But I was thinking, "What if I can actually do a whole Google App Engine API directly on JBoss or other open source libraries? To start off, let me see what API in the Google App Engine is the most complex. If I can do that one, I could probably do others as well." And we started with datastore. It turned out that wasn't too difficult, thanks to the Infinispan project, which is another JBoss project. So CapeDwarf was gradually promoted into a real project, I got additional resources to help me out, and I was able to do like, 50% on CapeDwarf, 50% on Weld, and do some Ceylon in between. Since CapeDwarf spans across a few other JBoss projects, we work with those projects closely, contributing patches, providing tests and feedback.
InfoQ: So how did you come up with the name CapeDwarf?
Justin: That came up with the help from my friend Dejan. We had a number of names. In the beginning it was Lhotse, which is the fourth highest mountain in the world. And nobody knew the name! So I had to change it. And then I was thinking about different things, and one of the names was Chameleon, which is, it can somehow change colors, can adapt to the change, whether it's Google App Engine, or a JBoss AS. So the name quite fits, but in the case of Red Hat, you have to put the name through legal, the legal has to approve it, and of course, they didn't approve - Chameleon was too broadly used. So then, Dejan started typing out the names of different types of chameleons, and CapeDwarf showed up, and I liked the name. So that was how the name came up.
The logo was a different story as well. We started off with ideas of a chameleon, and then we looked at it, feeling that the form is really familiar: SUSE Linux. So we ended up with a dwarf with a cape.
InfoQ: Cool. So currently, how many engineers are working on CapeDwarf?
Justin: Two and a half. I am the founder and the lead of the team - although it's a really small team. Back in the office in Slovenia, which is a small office of 5 engineers, 2.5 are working on CapeDwarf, which is me, Marko [Lukša], and Matej [Lazar]. Matej is an OpenShift guy, helping us put CapeDwarf onto OpenShift. So I count him as a half.
InfoQ: So do you work in an open source way? Are there developers from the outside joining in?
Justin: This project is publicly available from day one. For various reasons, we haven't put much effort into advertising, pushing it more to the public. At the beginning of the project, we were somehow waiting for the JBoss AS7 to be published - that is unfortunately not happening for various reasons as well. But yes, when it is finally released, we are hoping to get more people using it. What's important is what we offer - we offer something in-between the Google App Engine SDK and AppSpot. There should be a reasonable demand. I think if you have a Java shop running on Google App Engine, and you want to move the standalone application to a production environment, you can take the middle piece - CapeDwarf - run things, debug a bit, and then ship them to an AppSpot environment. And they don't need to change their code at all.
InfoQ: That's a good thing. So what difficulties have you encountered in this project?
Justin: As much as I like bytecode hacking, I'm not really sure that's the proper way to do it. That might not be the way we want to do it, but that's how it's done at the moment. The other problem that we see is actually how to test the things we do - it's more like a chicken and egg problem of testing things. The biggest problem is still the AS, because the development is currently depending on the snapshots of the AS. Our development environment is based on the build configuration, so if the build configuration in the upstream changes, we get an error: we need to somehow figure out what has changed, and copy-paste that as well. That's the biggest problem.
InfoQ: Things could be easier if you used a stable release.
Justin: Yes, but the latest stable release is 7.1.1, which is too old. The implementations we use are implemented in the upstream, and the upstream will eventually become a release.
InfoQ: So you are trying to get CapeDwarf into the upstream, then?
Justin: Well, there are different discussions on this. CapeDwarf isn't the only extension or new sub-system to the AS that wants to go into the upstream. There are TorqueBox, SwitchYard, and many other projects, so having all these extensions in the upstream might not be a good idea - I think this will create more problems than solve them. So at first, we had our own branches of the AS, which included the CapeDwarf integration inside; then, we extract it out, and overlay it on top of the AS. I think that's a better way to do it. Once the new version is released, we don't need to make changes to it, it will be much much easier for us.
InfoQ: So before you started this project, did you go out and look around to see whether others had done similar things before?
Justin: Definitely. I don't want to do things that are already done. Although sometimes it's good to do things that are already done, if you do it better. In this case, there are existing projects, such as AppScale done by students from UC Santa Barbara, but they do it differently - they do it on a larger scale, they support all the languages: Python, Java and Go, supporting different databases at the back. I did look at it, and I tried to set it up, but it was a huge pain. So I thought, "That's not how I want to do it. I want people to be able to just click away." And in our case it's just a command line: few or no configuration tweaks, and run. If you need a cluster, you just bring up a couple of nodes, and if you are familiar with JBoss AS, it's out of the box right away.
InfoQ: Did you talk with the GAE guys? Any stories to share?
Justin: Not many stories to tell yet. But yes, we engage with them quite a lot, but most things are dealt with at a private level.
InfoQ: During your 10+ years as a software developer, did you ever experience some bottlenecks?
Justin: I started off doing Mathematics, and my whole family - my father and both my brothers are software engineers; the computer was always present in my family. So I'm used to PCs and all this stuff from a young age. But then I never thought I would make a living out of this. So at the end of the third year of university, I was thinking, "What should I do? Academia or IT?" First I joined one of Slovenia's biggest Java companies, and I learned really fast; then I moved to a smaller company, getting engaged in an interesting energy consumption project. At one point I started contributing to JBoss a lot, as part of our work on the energy portal project. That project was running on all bench of snapshots - Hibernate snapshot, EJB snapshot, AS snapshots. I was maintaining all that, fixing bugs. I shamefully admit that I was actually using Spring at that time :-), but I brought up a library that bridged Spring and JBoss, a project Snowdrop. Then I was invited to do a talk at JBoss World to share what I had done. After that they made me an offer. So I was thinking, "What do I have to lose?" In these days, being a good programmer, means it's quite easy to find a job. So I had nothing to lose. And it has really been a nice 6 years.
About the Interviewee
Aleš Justin was born in Ljubljana, Slovenia and graduated with a degree in mathematics from the University of Ljubljana. He fell in love with Java ten years ago and has spent most of his time developing information systems, ranging from customer service to energy management. He joined JBoss in 2006 to work full time on the Microcontainer project. He currently leads the CapeDwarf project, whilst still contributing to Application Server, Weld, Ceylon and many other JBoss projects.
Note: This interview was initially published on InfoQ China.