|By Janice J. Heiss, July 2009|
This series of interviews spotlights Java Champions, individuals who have received special recognition from Java developers across industry, academia, Java User Groups (JUGs), and the larger community.
Bio: Alan Williamson, named the UK's first Java Champion in 2006, has spent more than 15 unusually productive years as a developer. He graduated with full honors in computer science from the University of Paisley in Scotland in 1994. He was for several years editor in chief of Java Developer's Journal, a major resource for the Java community. In 1998, he created the BlueDragon Java ColdFusion Markup Language (CFML) runtime engine that, among other things, powers MySpace.com. He works as a consultant to many startups and more recently cofounded aw2.0 Ltd, a software company specializing in deploying software solutions within cloud networks.
On November 20, 2008, he conducted the first-ever immersive cloud computing daylong boot camp, and in January of 2009, he was named editor of the new Cloud Computing Journal .
A previous interview focused on cloud computing. Here we explore Williamson's work with BlueDragon, the Java EE platform, and his reflections on Java technology.
"I was doing a lot of consultancy, and everyone wanted the same thing, 'Can you give us access to this database on the Web?'.... So I came up with a really simple templating engine that worked beautifully, and BlueDragon evolved from that."
Williamson: The full story is on my blog, but in summary, it started as a simple servlet created to build HTML pages from data sitting in databases. I was doing a lot of consultancy, and everyone wanted the same thing, "Can you give us access to this database on the Web?"
In the old days, it was a servlet per page -- this predates JavaServer Pages -- but I realized I was doing the same thing again and again. So I came up with a really simple templating engine that worked beautifully, and BlueDragon evolved from that.
JSC: BlueDragon now has an open-source version: Open BlueDragon, the J2EE CFML engine and alternative to Adobe ColdFusion that was released as a GPLv3 open-source project in May 2008. What are the benefits of working with Open BlueDragon?
Williamson: Where does one start? The real benefit comes from working for any open-source project -- transparency, flexibility and community.
CFML was, in our opinion, the underdog for web scripting alternatives when compared with the likes of PHP and Ruby. CFML is a top-rate high-performance scripting language that makes the building of highly scalable web sites a piece of cake.
It's the quickest way, for example, to build and consume web services. For a while, I did very little Java coding, because everything I was doing could be done in CFML, particularly when working with databases.
JSC: You created Blog-City.com, which you describe as a complete online blogging community, built with your own BlueDragon engine. Tell us about it.
Williamson: My wife actually runs and maintains Blog-City.com, while I provide the underlying architecture -- it's a true family affair. Blog-City has been powering blogs for more than six years now, all on the BlueDragon Java platform.
A lot of what is in BlueDragon was tested under real-world load at Blog-City. It allowed us to quickly optimize memory usage and develop new tags for clustering over a wide range of machines. Blog-City is and always will be a labor of love. We aren't interested in making it the next TypePad, because that would take the fun out of it. That said, it has grown much larger than we ever expected and pays the bills, as my father would say.
JSC: Java EE expert and fellow Java Champion Adam Bien points to three big fallacies about Java EE technology: First, believing that J2EE is complex; second, believing that Java EE 5 is easy; and third, believing that distributed programming could be simpler. Do you agree?
"The fundamental problem is that Java EE got so big in the first place. It reaches into many areas, each one a completely separate discipline."
Williamson: I understand where Adam is coming from. The fundamental problem is that Java EE got so big in the first place. It reaches into many areas, each one a completely separate discipline.
If you take Java EE in slices, it is relatively straightforward. But the harsh reality is that very few organizations are required to interact with all of it simultaneously, so why do we lump everything together and expect application servers to implement the full gamut?
On the point of distributed programming, it's not a case of it being simpler, it just requires a different mind-set. Most developers still don't get multithreaded applications, and distributed programming is not dissimilar but up a level of abstraction.
But there are lots of wonderful examples of real, easy distributed coding at the moment -- REST, for example. Without that simplicity, Ajax would never have taken off as quickly as it did. SOAP, for example, is way more complicated than it should be. The vast majority of uses of SOAP could quickly be replaced with a REST/JSON alternative with no loss of service. So as for distributed programming being simpler, there are definitely complicated and convoluted ways of doing things!
It reminds me of the old EJB vs. servlet debate. The vast majority of people using EJBs in the early days didn't really need that level of abstraction or complication. James Gosling threw his hat into the ring when he said that nothing could be done in EJB that, with good coding practice, couldn't be achieved in servlets.
"Design by committee is the death march for any project, whereas divide and conquer is a much better approach. The key is to clearly define the API or at least the boundaries which small teams can adhere to. Knowing they have a specific contract to service frees them to be independent."
"There seems to be a fashion to return to simpler days -- POJO (Plain Old Java Object) is all the rage these days. We've become abstracted so far from the original problem that we don't actually know what problem we are now solving."
There seems to be a fashion to return to simpler days -- POJO (Plain Old Java Object) is all the rage these days. We've become abstracted so far from the original problem that we don't actually know what problem we are now solving.
JSC: Bien also says: "Large-scale IT projects are inherently inefficient. It's a misconception to even talk about a large-scale project. The trick is to divide a huge project into small, two- to five-member developer teams that can act independently and be responsible for particular parts of the project. This is a challenge, but it's worth a try. Only then will developers identify with the code and feel responsible for it." Does your experience confirm this?
Williamson: Without a doubt. For all the pontification about open standards and open design, the reality is that coding is part art, part science.
Would the Mona Lisa be as beautiful had it been done by a full team of 10+ artists? Of course it wouldn't.
Yet companies insist on throwing resources at projects: Nine mothers will not make a baby in one month. Design by committee is the death march for any project, whereas divide and conquer is a much better approach.
The key is to clearly define the API or at least the boundaries which small teams can adhere to. Knowing they have a specific contract to service frees them to be independent.
JSC: As the editor of Java Developer's Journal for several years, you have carefully observed the evolution of Java technology. What has surprised you the most? Is there anything that you utterly failed to anticipate?
Williamson: Great question. I had thought we had written off the client side, so JavaFX surprised me. We failed to recognize the importance of the browser. That Swing didn't take off was no surprise to me -- no matter what OS you ran it on, it never looked good and always felt slow and cumbersome.
I had greater hopes for JavaServer Pages to really make an impact in the world of server-side scripting, but PHP and ASP became popular. That said, Java proved a great building block for us to produce CFML, so I can't complain that it didn't take off! Also, I felt that Java was very slow to offer native XML support in the JDK. Why did that take so long?
Looking at the last 10 years, the biggest surprise is that the JVM isn't part of the DNA of most operating systems. I still have to manually install it, whereas Python and Perl are ready to run straight out of the box. I don't even have to worry about them not being there. It surprises me that after 10 years people must download and install it.
JSC: You have a long history of involvement with open-source software. Virtual reality pioneer Jaron Lanier writes that "a politically correct dogma holds that open source is automatically the best path to creativity and innovation, and that claim is not borne out by the facts." He says that the kind of radical creativity he values most has not come from open source. Your thoughts?
Williamson: I agree. The quality of software has nothing to do with whether it was developed behind closed doors or in the open. In fact, most development is done on a one-by-one basis, no matter where it eventually appears. If your development team has a code-review policy, they are likely to pick up any problems that an open-source project would have. I write commercial software, and I write open-source software. They are of equal quality.
It angers me when I hear advocates claiming that open-source software is better, because it's a slap in the face to the legions of people employed in the world of commercial software development. Is their contribution not counted?
Open source has its place in much the same way that commercial software does. Both will happily coexist for a long time.
JSC: What are some common challenges that open-source communities face?
Williamson: The key is listening to your community and figuring out if your project is indeed focusing on their needs and not just your needs.
A successful open-source project understands they are in the business of providing software, albeit at a zero-dollar cost, but it's a business nonetheless. It requires dedication and passion.
While I worked as a technical evangelist at SpikeSource, I was surprised by just how many open-source projects come and go. People are under the illusion that just because they are working in open source, a community will magically appear from nowhere and support them. Marketing and evangelism are still required, and the best route for that is through blogs and forums.
Stop selling the promise of tomorrow and instead focus on the reality of today.
JSC: You have mentored small Java teams on the challenges of handling and applying new technologies. Do you have any advice to pass on?
Williamson: I think the best advice is to try not to rush too fast into the new ways of doing things. For example, we are only starting to deploy generics in our solutions, largely because the JVMs we had to support in the field weren't up to standard.
It's very easy for a developer to get seduced by shiny new things that somehow make what you are already doing seem obsolete. This isn't the case.
The other piece of advice is to get out into the community. There are so many great forums and developer sites and blogs that, even as an onlooker, you'll learn a lot. It continually amazes me how many developers I come across that don't even have an RSS reader. There's no excuse in not getting involved, even as a listener. Ten minutes a day browsing the latest articles will yield huge dividends for your development career.
JSC: What's the most fun you've had working with Java technology?
Williamson: Writing the initial BlueDragon engine, or TagServlet as it was called then. I felt a great buzz and excitement around the construction that sapped up my days and nights. Of course, that was before I had a small family.
Gone are the days of starting development on a Friday lunch only to look up and see that it's Sunday evening!
JSC: Do you have any advice to someone just starting out as a Java programmer?
Williamson: Don't try to learn the whole JDK. Start out slowly and get the fundamentals of object design sorted, and the rest will simply come.
The biggest problem isn't "how" do you do something in Java, it's "what should" I do? Solving the problem is the key, the implementation is a distant second.
Don't get fooled into thinking that taking the Java certification exam will make you a better developer. Instead, take that time and join an open-source project and look at how others develop code, and learn from their choices. You can ask them why they went down a certain route, if you don't see it yourself.
Not enough young developers use open source to learn.
JSC: What is the Java class that you couldn't live without?
Williamson: Had you asked me that a few years ago, I would have answered
System.out.println -- still the fastest and quickest debugging tool a developer can have.
"I have fallen in love with JMX and the power it has to offer. This is the best window into a running system that you could possibly have."
This is the best window into a running system that you could possibly have. The ease with which you can turn any object into an
MBean by simply implementing an interface named
MyClassMBean makes it a no-brainer for anyone.
To be able to attach JConsole to any running JVM and get a window into a live system without disrupting it has made profiling and fault finding a breeze now. The vast majority of my core classes now get
MBean'd up without even thinking about it.
JSC: What do you enjoy most about programming? What do you enjoy least?
Williamson: When I'm coding, I believe nothing is impossible. What I am about to create is going to solve a problem. It's a huge buzz. Coding can also be very frustrating. There's nothing worse than relying on a third-party library for something when it's not doing it right. So the hoops you have to jump through, assuming you know the hoops in the first place, can consume hours. I have to remind myself that, if it were easy, it wouldn't be fun.
JSC: What has been your biggest surprise in working with the Java programming language?
java.lang.String is marked as final! I wish it weren't. There is so much extra functionality that string handling requires. If I could just override the beast and add in what I feel is missing, then life would be so much easier.
JSC: What's the strangest thing about the Java platform?
Williamson: For all its openness and "write once run anywhere" quality, I still feel it's missing a trick by not hooking into some specific platform facilities.
A number of projects attempt to remedy this, but I think this should have been part of the core JVM. For example, there are basically two types of file systems, Windows and *nix. Why isn't there a
I'm a big supporter of Eclipse's SWT framework way. I have coded in both, and I prefer SWT over Swing. That I can make my desktop application look and behave exactly like the native is a great boon. I believe that SWT never got accepted into the family because some folks didn't like the fact it was tied to a platform, even though all the major platforms were supported.
JSC: Can you describe the process of writing code?
Williamson: I do a lot of whiteboarding and drawing of boxes. When it comes to writing code, I do a lot of boilerplating, laying out classes, method calls, and so on, and I don't focus on the details of the methods. So lots of
return null; everywhere.
I can visualize the solution very well, so when I see the class hierarchy set out, then I know it will work before I get anywhere near implementing the real meat of the code. Some people use other tools, such as UML, but I always found that it gets in the way.
JSC: What technical insights into the Java programming language have been most important to you?
Williamson: I have learned so much from Kirk Pepperdine on the underlying JVM and power that is offered to us, the humble developer.
If you were to ask the average developer how many switches there are to the JVM, they would probably answer two or three, maybe five, tops. But there are over 500, and I bet Kirk knows every single one.
JSC: Do you have any tips about writing better code?
Williamson: Keep it simple, real simple. Try not to do everything in one class, but conversely don't abstract too much.
Make sure you have a coding buddy, someone you can throw code to and find out what they think. You need that sounding board, if only to validate that the path you are going down is the right one.
Also, assume that things will go wrong. Never assume that the method before you is cleaning up data or checking for nulls.
Exception handling is still one of the biggest problems of coding: when to do it, when to catch it, when to throw it. And remember, finally, it's your friend -- particularly when you're handling any I/O operations.
JSC: Is there any basic software problem that you would most like to solve?
Williamson: Email. It's still the killer app, the one thing we all check daily.
I would love to write an email solution that allowed a desktop, web, and mobile view. My Thunderbird is the closest thing so far to an ideal client, but I want it on the Web.
Off the back of that, I would love to stop the world spinning and write a proper address book application. I have contacts littered everywhere -- BlackBerry, web, email -- and not one of them talks to each other!
Part One of Alan Williamson Interview
Alan Williamson's Blog
Cloud Computing Journal
Better Programming With Java EE: A Conversation With Java Champion Adam Bien
Java Performance Tuning: A Conversation With Java Champion Kirk Pepperdine
More Effective Java With Google's Joshua Bloch