Category Archives: Java

In All Fairness to CloudBees

** EDIT ** Please make sure to check out the comments section for some additional information from a CloudBees engineer. He was kind enough to explain to set up their build environment to support some of the tools I mention below.

Today, due to some frustration I experienced, I tweeted:

In fairness to CloudBees, I should explain further.

Jenkins is, in my opinion, the reference implementation of continuous integration. It’s really great. While it favors Java, it’s not uncommon to see folks use it to run iOS builds, Ruby, Node, you name it. It’s very extendable and has an active developer community. I’ve had significant success using it for the last few years and, earlier this week at my new gig, my team and I setup an environment.

Hosted solutions can be a great idea because they often handle all the stuff about hardware and OS setup I don’t really care about. I am not a system administrator and I didn’t want to provision and manage a VM just for CI if I could help it (I know, being lazy but honest here). CloudBees seemed like a great choice and we had it up and running in literally minutes. It supported Gradle and Grails right out of the box (currently pieces of our software stack), has GitHub integration and other cool features. So far, pretty big win.

However, I’ve grown very used to using Jenkins for things outside of stock Java builds. For example, you can use Jenkins to test JavaScript (see this for an excellent example). We have also been using JRuby and Rake for pieces of our application stack and Jenkins has nice support for that also.

The hosted version, however, didn’t support much outside a stock Java (Ant, Gradle, Maven, Grails) build. I don’t necessarily blame them as trying to keep up with versions of Node, Ruby, PhamtomJS, whatever is probably outside the core competency of CloudBees. They are, first and foremost, a Java hosting platform. However, it sort of sunk us. After trying workarounds for a few hours, my team and I decided to move over to a RackSpace virtual host and setup our own custom solution.

So, to be fair, CloudBees hosted Jenkins (and even their application cloud) is an excellent choice if you are interested in building Java/JVM applications and don’t mind not having support for other, perhaps more fringe, tooling. The system itself ran flawlessly and worked very well for the more common tasks we sent its way. However, it’s just not a long term solution for the things we’re looking to do.

To quote Wheaton’s law:

My tweet was a little uncool and not very fair; I hope this explains it better!

See Dart … Java?

About a month ago, Google made headlines when an email describing ambitious plans to re-create JavaScript was leaked to the web. This email created quite a stir and spawned numerous debates ranging from the hubris of Google in trying to single-handedly replace such a ubiquitous staple of the web to the possible merits of Google’s decision on a technical level and the kinds of exciting innovations that could occur.

While I personally didn’t feel great about Google’s actions, I decided to reserve my public judgement for the time when Google actually released the language. Two days ago, that finally happened. So, let’s take a look:

main() {
  print('Hello, Dart!');

Ummm … ok. This chunk of code looks similar to JavaScript, so that’s not all bad. However, I was really expecting something more groundbreaking in terms of syntax. While I don’t loath semi-colons as line endings (you have to have something, right?) the new trend these days is to exclude them. Specifically coming from a JVM perspective Scala, Groovy and Clojure, three of the most popular Java alternatives, are happily semi-colonless. Also, as Google has deep Python roots, I expected they’d create something with a more “modern” syntax. But that’s ok … I can live with semi-colons. Let’s dig a bit through the Dart sample source code (can currently be found on Dart’s Google code page).

Check out (I’ve removed the comments for brevity):

class BiIterator<E> {
  ObservableValue<int> currentIndex;

  List<E> list;

  BiIterator(this.list, [List<ChangeListener> oldListeners = null]): currentIndex = new ObservableValue<int>(0) {
    if (oldListeners != null) {
      currentIndex.listeners = oldListeners;
  E next() {
    if (currentIndex.value < list.length - 1) {
      currentIndex.value += 1;
    return list[currentIndex.value];

  E get current() {
    return list[currentIndex.value];

  E previous() {
    if (currentIndex.value > 0) {
      currentIndex.value -= 1;
    return list[currentIndex.value];

  void jumpToValue(E val) {
    for (int i = 0; i < list.length; i++) {
      if (list[i] === val) {
        currentIndex.value = i;

When I first saw this code, I instantly recognized a very similar syntax to Java 5 generics. Eerily similar, in fact. As powerful as Java generics are, not too many people like the syntax. To port what many consider to be kruft to a brand new language is an odd choice.

Another interesting thing about this code is the inclusion of strict comparison operators (i.e. ‘===’ and ‘!==’, see line 31 for an example). While the use of these operators is instantly recognizable to those of us who regularly use JavaScript, I think it a very odd decision to include these operators in a brand new language. They are, essentially, a JavaScript oddity that often confuses people when they first learn the language.

So far, things aren’t looking great for Dart.

There is hope, however: Dart has great support for concurrency. It implements a version of the Actor model (see for details) placing code into Web Workers behind the abstraction. Concurrency is rarely easy and the Actor model is a great way to abstract that kind of complexity away from the developer.

So, let’s take a look at a basic Actor (Dart’s interface is called an Isolate):

class Printer extends Isolate {
  main() {
    port.receive((message, replyTo) {
      if (message == null) port.close();
      else print(message);

main() {
  new Printer().spawn().then((port) {
    for (var message in ['Hello', 'from', 'other', 'isolate']) {

Huh. It doesn’t look terrible, but I’ve been doing a lot of Scala development recently and Scala also happens to have actors. Let’s take a quick look at how Scala might implement the above code:

import scala.actors.Actor._ 
val portActor = actor {
    while (true) {
        receive {
            case msg => println(msg)
List("Hello", "from", "other", "actor").foreach( word => portActor ! word)

Granted: these are both contrived examples. However, look at the Scala version. It’s doing some tricks like importing a static Actor but it is still, at least to my eyes, much more readable and elegant than the Dart version. While it’s nice to have an actor-based model for client development, I feel like Dart’s falls short in comparison to Scala’s state of the art implementation. Again, considering this is a brand new language, this is puzzling.

Finally, Dart itself can either be executed in a virtual machine or transpiled to JavaScript for execution in a browser. Since most browsers outside of Chrome won’t have much support for a native Dart VM in the near future, let’s take a look at Dart’s transpiling overhead. This is probably all you need: Dart’s ‘Hello World’ application transpiled to over 17,000 lines of JavaScript. Wow. To be fair, this overhead has to do with setting up Dart’s optional typing system and other niceties of the language which is more akin to including a library. As such, this isn’t an apples-to-apples comparison with JavaScript itself or something like CoffeeScript which transpiles in a more one-to-one fashion.

But still. Wow.

So, at least for now, it seems like Dart is a bit of a snooze. As much as I was disappointed in Google with not being more open about the development of Dart, I was also excited in seeing something that would simply blow away JavaScript and set the stage for something ground-breaking (maybe something like “ScalaScript”). Dart is not that. Core Java developers will likely feel right at home with Dart, but I can’t see the huge community of client-side JavaScript engineers being very excited about this.

Dart, I am disappoint.

Early Impressions of Some New Choices

My team and I were recently tasked with a pretty monumental project. We are basically building the services that will power a whole host of extremely high traffic websites that can do everything from paying a bill to streaming video content to an iPad. The complexity of this type of project is very appealing and I’m really happy be a part of something this ambitions.

As part of this endeavor we were given the freedom to choose just about whatever tools and technologies we wanted to build the most scalable, maintainable and bullet-proof system we could. After about a week spikes on different languages, frameworks and tooling we came to the initial conclusion that we would adopt:

  • Git for version control
  • Spring for DI and other stuff (which we since removed, see below)
  • Scala as our primary development language
  • Gradle for our builds
  • MongoDB for persistance

This blog is one of many to report on my impressions of these choices and the tradeoffs they are (or aren’t) causing us to make versus a standard J2EE/Spring Java project that just about everyone on my team has done in the past successfully.

First, Git.

Git. Is. Awesome. Seriously, it is amazing. I’ve been using Git for about two years but, before now, only in very small projects. I thought it was good before, but I’ve really grown to love just how much flexibility and speed it buys me personally not counting how much it buys our team in terms of ease of branching and an easy (now) to understand code history. If you haven’t yet adopted Git as your SCM system, you absolutely should.

Secondly, Spring.
We’ve all used Spring pretty heavily in the past and have a good track record of success with it. However, as we began coding our DI, we came to a very startling conclusion: we probably don’t need it anymore.

Relying on our experience with DI in general and our understanding of what Spring does “under the covers” as it wires objects together, we were able to create a native Scala DI solution that is statically typed, easy to understand (read: no XML or annotations) and, given that it’s simply part of the language, extremely quick to bootstrap. There is no ApplicationContext to wait for or mock for testing. It does its work when the classes are executed (and slightly later if we’re using the lazy modifier which we usually do) and that’s that. While I’m sure we’ll be refining this solution over time, the fact that we own it and it works as well as it does for us makes me suspect that we, as a team, have grown “beyond” the need for Spring. Spring helped us (and me in particular) understand the need for things like DI and AOP and caused me to think of my code in a very decoupled manner. Thanks Spring, but we’ve grown up!

Next, Scala.
I’m not sure what I think of Scala yet. It’s a daily thing. Coming from a lot of Groovy and JavaScript work, I have grown to like the free love devil-may-care type system. Some of the recent code I’ve written in those two languages is the best work I think I’ve ever done. However, I do see the value in a stricter type system and there are many things about Scala I love.

The biggest concern I have is how ridiculously complex Scala can be if you let it. The community has yet to (as far as I can tell) establish a concise set of patterns (something like Effective Java) and many teams (including ours) spend a lot of time trying to figure out what esoteric features to take advantage of and which to ignore. The exciting thing about this is that we are building our own Scala “way” of doing things internally in our team. That’s also the scary part. However, so far, it’s been relatively smooth aside from those times when I think “my god this was so much better in [Groovy|Java]” which are becoming less frequent as I continue to learn the language.

I had high hopes for Gradle when we started the project. We moved from a combination of Gant and Maven and, at first, we were loving the combination of convention and extendability. It really allowed us to customize our build and do some pretty neat stuff with very little effort.

My biggest complaint, which is starting to sour my whole opinion of the tool, is how slow it is. Running gradle tasks in our project on a quad-core Xeon takes 17 seconds! Running a build from scratch takes almost 30 minutes. And, since there isn’t yet great IntelliJ support for it, running a gradle idea (which I do several times a day to refresh the .iml dependencies) takes 4 minutes.

These are all unacceptable timeframes in my opinion. Granted: much of the 30 minutes I mentioned above is spent downloading dependencies (perhaps the majority of it), but the other tasks download nothing and still take far too long.

As gross as it sounds, I’m actually missing Maven. Not necessarily for configuration and dependency management (which were and still are a pain in many cases) or its contrived complexity and “xml hell” but more because it was faster and had first-class IDE support. These things are all missing right now with Gradle and I feel like it might be causing us to lose velocity rather than gain it as the time saved setting up the project does not match the time we all spend waiting for tasks to complete on a daily basis.

We may be doing something wrong and I’m open to doing what it takes to modify our setup, but I feel like what we’ve done is extremely reasonable and a relatively “common” case in terms of project structure and dependencies. To verify that assumption, I ran the same types of commands using another complex project: Gradle itself. I had similar results to those I see in our project. I’m hoping things improve in this regard after a smart colleague of mine attends Gradle training next week.

Finally, MongoDB.
I don’t have much of an opinion on this one as we haven’t integrated to it just yet. I’m interested to see how it compares to CouchDB as that’s where my previous NoSQL experience lies.

Again, I’ll be writing more as we get farther into the project. I feel (mostly) pretty good about the decisions we’ve made and the team I’m on. It’s been, and will continue to be, an awesome ride!