Archives

photo credit: Center for
American Progress Action Fund

Harry Reid hung on to beat Sharron Angle this past election day. It wasn’t that the voters of Nevada loved him, it was just that the other candidate was so much worse. Much the same can be said of Java for enterprise applications: meh, but the alternatives are worse.

That’s not surprising, as most of the alternatives to Java have focused on the things that made Java such a poor solution for webapps — over engineered, thousands of different ways to roll your own application architecture, slow dev/compile/test cycles because of the JVM. But those same alternative left the back-end enterprise space alone.

Back in 2005 or so, the rise of Ruby on Rails hit Java like a gut shot. Java book sales started a free fall. But when it comes to the enterprise, i.e. highly scalable, high performance backends, Java is hanging tough. Over the last two years we’ve seen lots of hybrid Rails front-end, Java back-end solutions. The Rails part gives you the highly productive web development, the Java back-end gives you the highly scalable architecture.

This story should be familiar to anyone who has followed the first big Rails success story: Twitter. They moved to a Scala back-end for a variety of reasons. And of course Scala runs on top of the JVM (much like Groovy, it is a mutant cousin of Java). The other big competitor to Java in the enterprise space — C# — is still trying to have it both ways, competing with Java for the back-end services, and with Rails for the front-end webapps. I think MS is going to have to commit one way or the other rather than sitting between all chairs.

photo credit: °Florian

Yes, Cloud Foundry has been acquired by Spring Source and seems to be morphing into a for-pay service, and there hasn’t been a new build packaged on the Cloud Tools project page since January of 2009, but if you dig in the SVN repo, you see there’s a bit of activity. Before I try building from source, I wanted to see how hard it would be to get 0.6 Grails plugin working with a Grails 1.1.1 app.

Well, harder than I thought. There’s a real lack of documentation around cloudtools for one, and the radio silence on the project page over the last few months hasn’t helped. Fortunately, Don over at AlterThought has put together a nice post that covers most of the pitfalls and problems with the CloudTools Grails Plugin. A few things they don’t address and I thought I’d throw in here:

Well, GWT 2.0 RC1 (yes!) is out. I was going to wait for a while with some of my new projects until switching them over to GWT 2.0, but given the pace of the GWT 2.0 project, I may just switch them over now rather than going through a painful migration.

I’m especially eager to use UiBinder to do declarative UI creation. Just specify how your interface should look in XML:

Whenever you can get a free, publicly available place to deploy your applications, your first instinct is to grab it with both hands. Google App Engine is one of those places. Each developer can deploy up to 10 different apps in development mode.

I’ve been working on a grails app recently that uses the grails App Engine Plugin. Along with the GORM-JPA Plugin, which gives you some  of the usual grails GORM goodness, you can write some reasonably interesting grails apps.

Just got my hands on a copy of Android, Wireless Application Development by Conder and Darcey and have been working my way through the first three chapters (really, the actual development starts in chapter 3).So far so good. Some of the pseudo JVM (Dalvik) takes a little bit of getting used to, but it’s not really that bad. I’d say that the real thing that pops out at me is that I want a way of developing iPhone and Android applications at the same time, without having to jump through hoops to do so.

I should have a full review of it up in a week or two.

I finally have some small amount of spare time to start working on my Griffon PureMVC plugin. One of the first things to think about is where to we make the marriage between the two frameworks?

Griffon has Models, Views and Controllers, as does PureMVC (actually, it has Commands, Mediators and Proxies, which essentially perform the tasks under MVC). My initial thought is that Griffon’s MVC triads really perform the tasks of a complex view, and PureMVC wires these complex views together via it’s message bus. So, my thinking is to wrap each MVC triad into a Mediator, with the Mediator mostly talking to the Griffon controller and perhaps the Griffon model.

I’ll make some more posts here as my thinking and experimenting evolves.

I have a short list of things that I don’t like about GWT. They are:

1. You have to use a special browser to debug in Java. That browser doesn’t always behave the way IE or Firefox or Safari does. And you need OS specific distributions which can make it a little tricky to share a project between developers with different OS platforms.
2. GWT apps download as a massive hunk of code. There’s no way to dynamically load code as you need it.
3. Building UI’s dynamically, through a sort of XUL mechanism is a pain in the ass for non-standard components. Just talk to the Vaadin folks about the hoops they had to jump through.
4. The annoying dependency on SWT for tests.

So, what does 2.0 promise? To resolve these four things, and a few more. Check out the GWT 2.0 Milestone 1 release announcement:

In-Browser Development Mode: Prior to 2.0, GWT hosted mode provided a special-purpose “hosted browser” to debug your GWT code. In 2.0, the web page being debugged is viewed within a regular-old browser. Development mode is supported through the use of a native-code plugin for each browser. In other words, you can use development mode directly from Safari, Firefox, IE, and Chrome.

Code Splitting: Developer-guided code splitting allows you to chunk your GWT code into multiple fragments for faster startup. Imagine having to download a whole movie before being able to watch it. Well, that’s what you have to do with most Ajax apps these days — download the whole thing before using it. With code splitting, you can arrange
to load just the minimum script needed to get the application running and the user interacting, while the rest of the app is downloaded as needed.

Declarative User Interface: GWT’s UiBinder now allows you to create user interfaces mostly declaratively. Previously, widgets had to be created and assembled programmatically, requiring lots of code. Now, you can use XML to declare your UI, making the code more readable, easier to maintain, and faster to develop. The Mail sample has been updated to use the new declarative UI.

Bundling of resources (ClientBundle): GWT has shipped with ImageBundles since GWT v1.4, giving developers automatic spriting of images. ClientBundle generalizes this technique, bringing the power of combining and optimizing resources into one download to things like text files, CSS, and XML. This means fewer network round trips, which in turn can decrease application latency — especially on mobile applications.

Using HtmlUnit for running GWT tests: GWT 2.0 no longer uses SWT or the old mozilla code (on linux) to run GWT tests. Instead, it uses HtmlUnit as the built-in browser. HtmlUnit is 100% Java. This means there is a single GWT distribution for linux, mac, and windows, and debugging GWT Tests in development mode can be done entirely in a Java debugger.

Looks like Xmas has come early. I’ve been working with the browser plugin for a little bit and it is just a joy to use. One down side, of course, is that Intellij 9.0 will be out of date re: GWT the day it is released.

Time to answer some questions about Griffon:

1. What is the size of the jar that gets generated for a Griffon jar?
   If you package it all up (‘griffon package’), then a vanilla Griffon jar weighs in at 4.7M. That’s mostly the Groovy runtime (4.4M) and the Griffon runtime (204k). If you’re concerned about download size for Java Web Start, then you won’t want to bundle it as a single jar, but rather let your users download the Groovy and Griffon runtimes once, then your app specific jar as it is updated.
2. Can Griffon apps be distributed via Java Web Start?
   Yes. When you run ‘griffon package’, you get an executable jar, an applet, a JWS app and a ‘zip’ that is structured as a directory with bin and lib subdirs and batch and shell files to run the application. In short, most ways that you may want to deploy the application.

There is even an installer plugin that allows you to package your app as an izPack (platform independent), RPM (Linux) or DMG (Mac) distribution. It will also create app (Mac) or exe (via JSmooth) launchers for Mac and Windows. Pretty sweet.

Recently I have taken a bit of a detour into the world of telephony, working with Asterisk-Java, which by itself is a very valuable tool, and worth knowing a bit about if you are integrating a system with Asterisk. While it is a Java-based library, I am integrating it into a Grails application.

We have a fairly comprehensive suite of unit tests asserting that desired behaviors are triggered upon certain events initiated through the Event API. This is made even easier, as usual, with Groovy– specifically on the testing front. Here I show two hypothetical test cases, followed by supporting code that works specifically with the Asterisk-Java classes…

While never untrue, it is more of a necessity now, that a programmer should know more than just one language or framework. After being a focussed Java/J2EE developer for a long time since college, in the last couple of years, I plunged into .NET, Ruby/Rails and then Javascript/prototype/jQuery etc and now onto groovy/grails. With name like Erlang, Scala, Compass, git, blueprint, flex flying around us everywhere, it can be overwhelming and we need a plan to pick, peruse, acquire them. Here is a list of things I do when learning a new skill.