It should come as no surprise to any well-informed Web 2.0 developers out there that the Ajax tech box can quickly morph into Pandora's box if not handled with care. This is mainly due to the fact that the XMLHttpRequest object offers a great flexibility to the developer as to when and how often HTTP connections to remote servers can be initiated. As is often the case, this increased flexibility in managing the web application connectivity usually implies an additional cost when it comes to making sure that the communication layer is kept clean and the remote servers are not put under an unnecessary heavy and potentially lethal load.

Experience has shown that web developers are more concerned about knowing when they have to initiate new connections than thinking about the conditions under which they should have to abort them. What this means is that basically very few developers make use of the XMLHttpRequest.abort() method. Worse, sometimes developers are aware of the problem and would like to make use of abort(), but they can't because the JavaScript framework/library they use does not provide support for it. Even worse, sometimes the framework/library does provide that kind of support but additional plugins of that framework/library deceptively break the contract.

On some project, we are using the jQuery JavaScript library and a host of jQuery plugins for enriching jQuery's core to best suit our needs. jQuery provides excellent support for Ajax by means of its general-purpose utility function called jQuery.ajax(). Other utility functions, such as jQuery.get() and jQuery.post() are merely facades that eventually call jQuery.ajax() for doing their work. All those utility functions return the XMLHttpRequest object that was used to make the Ajax request, so that the developer can get her hands on it, shall she have to abort the request manually.

One of the plugins we are using is the jQuery Form plugin. One of the useful features of that plugin is to provide a way to ajaxify any HTML form using the ajaxSubmit() method. The good thing with ajaxSubmit() is that it makes a good job of setting up and wrapping the call to jQuery.ajax(). However, the bad thing is that it breaks the contract of jQuery.ajax() in that it doesn't return the XMLHttpRequest object but the wrapped form element instead. Thus, there is no way the developer can abort a request initiated using ajaxSubmit().

There are many ways to solve this problem. One of them is to modify the Form plugin to return the XMLHttpRequest object but this would most probably break all the existing client code base. A second option is to use AOP in order to weave additional behavior into existing code. There are several solutions for doing AOP in JavaScript, but since we are using the jQuery library, it's nice to know that there is an AOP plugin for jQuery.

Basically, the jQuery AOP plugin provides very primitive support for weaving before, around and after advice into existing code as well as removing any previously weaved advice. Even though this plugin does not provide full-fledged AOP capabilities (i.e., no introduction support, no aspect modularization support, no wildcards in pointcut expressions), it is lightweight (943 bytes!!) and it does cover our need, which basically consists of wrapping all calls to jQuery.ajax() for registering the returned XMLHttpRequest object after letting the call proceed. The reason we have to be able to abort all ongoing Ajax requests is due to our page architecture. All pages are loaded by Ajax calls and other Ajax calls may happen once a given page chunk is loaded. When the user requests a new page, there is no reason to let any ongoing Ajax call proceed because the results eventually received from the server would not be used anyway. So, we have to cancel all ongoing calls.

In terms of implementation, our need would be covered by the following code. Our code is actually a little more involved than that, but the following code basically shows the main ideas of what we wanted to achieve:

var ajaxRequests = [];

//registers all unterminated Ajax requests
function registerAjaxRequests() {
	var advice = function(invocation) {
		var ajaxRequest = invocation.proceed();
		if(ajaxRequest.readyState < 4) {
			ajaxRequests.push(ajaxRequest);
		}
		return ajaxRequest;
	}

	$.aop.around({target: jQuery, method: 'ajax'}, advice);
}

// abort pending ajax requests
function abortAjaxRequests() {
	while (ajaxRequests.length > 0) {
		var ajaxRequest = ajaxRequests.shift();
		if (ajaxRequest.readyState != 4) {
			ajaxRequest.abort();
		}
	}
}

The job of the registerAjaxRequests() function is to instrument all calls to jQuery.ajax() and to store a reference to the newly created XMLHttpRequest object in the case we need to abort it at some later time (e.g. when a new page request has been made by the user). This function can be called anytime but we usually call it when the current page is loaded using jQuery's $(document).ready(...) handler.

The other function called abortAjaxRequests() can be invoked anytime existing Ajax requests need to be aborted. It will iterate over the array that contains the existing XMLHttpRequest objects and will invoke abort() on each of them if the call has not returned yet.

So, using the jQuery AOP plugin that heavily builds upon the dynamic and reflective nature of the JavaScript language, we could very easily get around a design flaw in the jQuery Form plugin which would prevent us from getting hold of the XMLHttpRequest object for aborting ongoing Ajax calls. I really do hope that the jQuery AOP plugin will eat some meat and provide a richer set of AOP functionalities in the future. But for now, it provides more stuff than we actually need.

I just got back from a talk by James Gosling titled the "State of the Java Universe" that was held within the Web's birthplace at CERN in Geneva, Switzerland. First off, for someone like me who professionally grew up with Java and its derivates, it was something of a special moment to see Java's father in real for the first time just in front of me and to actually get to feel his aura and to share his passion for what he has been doing over the past 30 years.

One of the small details that first struck me was that the guy was actually doing his presentation using JavaOS. It's always nice to see someone actually eating his own dog food, i.e. the same he's serving to the audience.

The talk, which he also gave back in September at JavaPolis 07, was organized along several axis.

First, he made a tour of the landscape telling us how ubiquitous Java has become and showing us the different universes in which Java applications were actually used and deployed, namely in the entreprise world, in standard desktop settings, in embedded devices and on smartcards. Then, he went on enumerating some unavoidable statistics that every well-informed Java aficionado already knows about: there are 5 billions Java-enabled devices running around, 6 millions Java developers, 10 millions JRE dowloads, and all that blabla.

An interesting part was when he actually mentioned some concrete examples of successful deployments of complex Java systems. The first noticeable example was the case of the Brazilian Healthcare System, which according to him is currently the largest Java-powered system on earth and whose cost of approximately $60M was entirely sponsored by the UN. "And it just works!", he added. Also worth mentioning were some of the giant telescopes that perpetually monitor the sky, the NASA's Jet Propulsion Lab systems, eBay auction engine, FedEx's 50 millions LOC Java platform, Sabre's Java-powered airline solutions, Nasdaq's trading platform, etc. I also detected that Java seemed to be increasingly used for powering robotics system. One of the best examples being ABB's robot powered by Real-Time Java and supporting a 10G acceleration with high precision. As a small anecdote, he told us that one of ABB's test cases for testing the robot was moving a croissant from A to B with a 10G acceleration without messing up the pastry. Hey, they did it and it seemed like quite an achievement!

One feeling he gave us was that the focus was moving away from Java (the language) towards Java (the virtual machine). He sees that Virtual Machine as actually being an integration hub between some supported development languages (among which XML, Java, JavaScript and Ruby) and the consumer devices on which the code runs.

Another axis he touched upon was the community aspect. He cited 7 main entry points to the open Java world (dev.java.net, openjdk.java.net, openjfx.dev.java.net, glassfish.dev.java.net, jcp.org, opensolaris.org and netbeans.org). Without delving too deep into the debate, he also explained the stance Java has with the open-source world and claimed that "Java has actually been open source since day one..." since we've always been able to download the sources of the JDK and the JVM. We all know that open-source means much more than that (especially the "contribution" part has been missing) and he is aware of that, too. One thing he said about this is that for a long time, the reason why they only allowed the community to contribute improvements and bug fixes was because most of the time the contributed bug fixes were actually causing more bugs in the JDK than they solved. Another problem they had when deciding how to make Java fully open-source was that there were "way too many open-source religions out there!" He went on explaining how they had a hard time choosing a licensing scheme. "We are preferring GPL3 over many potential candidates, and then the Apache folks are getting mad at us because we don't choose them." That was pretty much it for the open-source part.

Another big thing that seemed quite important to him was the current tooling offering. He started with "Folks, even though I was one of the first initiators of Emacs, please do me a favor and stop using it, it was a good idea 30 years ago, but things have changed." And then the speech went on talking about NetBeans and it's where it really felt more like a biz pitch and advertising than tech talk. He spent a third of the time praising about how great and nice and powerful and <name-your-superlative-here> NetBeans is. I don't question the greatness of NetBeans but it's just one IDE among many and it was certainly not worth spending 15 minutes on it, unless of course you have stakes in it. Anyway...

A final topic he touched upon was Java's performance. "The myth is", he started, "that Java is slow because it is interpreted." This was maybe somewhat true in the previous century but things have evolved and the truth is completely different nowadays. According to recent benchmarks, Java would outperform or at worst equal the performance of C/C++, and oftentimes tap on Fortran's shoulders ("except for matricies!", he admitted). The benches (among which SciMark, SciMark2, SpecJbb2000, SwingMark, Linpack) also show that Java's garbage collection is actually much more faster than malloc/free (e.g. when a huge amount of small objects need to be allocated and deallocated in a short time frame) and that dynamic compilation in many cases outperforms static compilation.

There are some evidence showing that the Moore's Law is flattening. Even though Java is a performant language and platform, he firmly believes (and he's not alone!) that developers should start focusing on delivering clean code and algorithms and use threading and parallelism to best serve their needs. "Developers should stop believing that Moore's Law will solve their performance issues", he said. To that end, the community is focusing on delivering a clean and simple platform exploiting a new persistence API and most of JDK 5's features, such as annotations and generics. He also briefly mentioned all the goodies that were scheduled for Java 6 (update N), Java 7 and Java FX. Nothing new under the sun here.

Another goal Java has been focusing on since the beginning was to strive for a clear, consistent cross-platform definition. And floating-point arithmetic was no exception. The problem lies in the strict conformity of the IEEE-754 standard which governs binary floating-point arithmetic. That's where the strictfp keyword that very few people understand came in. Basically, the problem with binary floating-point arithmetic is that Intel never implemented correctly the IEEE-754 standard and so they introduced the strictfp mode for developers who actually wanted strict IEEE-754 compliance whatever the platform they were running on. Concretely, one area were this problem becomes noticeable is with sine/cosine computations because the value of PI is wrong on x86 platforms as soon as you start delving too deep into decimals.

Up to this point, apart from the fact that it was actually cool to be in the same room as such an eminent guy, I did not really felt like I learnt something new. Maybe it was not even the point of my being there. A short Q&A session followed which is summarized next.

The first question that came up was whether Java could actually be used with Android, Google's new SDK for developing mobile apps. Gosling was a bit puzzled at first, paused for a minute and started like this: "Both are completely different, it's a complete mystery for us!" They've been talking to Google for a while but "they are not transparent at all and it's difficult to see where they want to get at. For instance", he said, "they've been talking about their GooglePhone at conferences and talks for over two years now, but as soon as people start asking about their business model, their speech gets different everytime. But I should probably shut up right now!"

The second question related to whether he thought Java processors were going bullish or not. Basically, there are two camps: the compiler folks who strive to create general-purpose things and the hardware guys who focus on delivering specific things. And the hardware guys almost always loose because the impact of the instruction set on the performance of applications has become quite negligible, so there is no point in trying to optimize on that front except maybe for very specific needs.

Then came the traditional question about how they make revenues on something they let go out the door for free. I won't delve into that since we all know how that business model works. Apart from "I cannot divulge numbers due to SEC regulations", he added "but we are doing pretty fine."

Then the famous question on Java vs .NET came again. Basically, his current experience is that there were currently zero .NET applications running on Mono because .NET applications need their Windows APIs. "A couple years ago", he said ".NET was a big issue for us, but now it's definitely not on the top of our panic list anymore." Mainly because Microsoft has put more resources into court cases and their Vista disaster than on trying to push the envelope further on their .NET implementation.

Another interesting question was whether he would do differently if he had the chance to start over creating the Java language again. He admitted that he would maybe start differently without really knowing how or where to start. "Maybe I would add closures and generics right from the start", he said and that "the network would still be the central piece of the language".

So all things considered, I didn't really learn anything new except maybe some nice information nuggets that came out straight from some crispy anecdotes. It was a really nice moment to share with James Gosling, the Passionate and James Gosling, the Sun Executive.