If you're using the Jaxer in Studio, the regular Studio update process will let you know there's a newer version of Studio, and you can update it directly.

If you're using the standalone Jaxer Package...

1. First stop Jaxer if it's running.
2. Then simply delete the jaxer folder in your Jaxer Package (or JaxerPackage) folder.
3. Finally, download Jaxer_update.zip and unzip it into your Jaxer Package (or JaxerPackage) folder, creating a new jaxer folder.

Jaxer works alongside a web server to process content. Today, it can work with Apache 2.x using the mod_jaxer Apache module bundled with Jaxer. It can also already work with Java-based web server Jetty, using the jaxer filter servlet now packaged with Studio and soon to be available standalone. It also works with Tomcat (details coming soon) and will be compatible with other Java web and application servers. We'll be working to expand the range of servers with which Jaxer works closely: to Apache 1.3, to IIS, and to others.

Jaxer currently runs on all recent Windows operating systems (including Vista) and on Mac OS X (10.4.9 and up, on both Intel and PowerPC architectures).

Linux support is almost here — we know that will be the deployment target of choice for many developers and IT shops.

Please see the Jaxer Security page. We will soon provide many more discussions about this critical topic, as well as best practices and expert opinions.

On the server side, Jaxer runs with full privileges, so it's not restricted from interacting with other domains. And on the browser side, accessing the server side is really, really easy. Put them together and you have a solution to the common cross-domain Ajax problem, that is, the restriction that browser code only make web requests within its own domain.

The original and still prevalent interaction between browsers and web servers is a (more or less) stateless request from the browser followed by a response from the server, and that's it. With the addition of XMLHttpRequest (or similar mechanisms) to allow request-response communications without refreshing the page, Remote Procedure Calls (RPC) are very natural to implement, and now Jaxer makes them downright trivial: a client-side function can simply call a server-side function that's been designated with the "proxy" flag, as easily as calling another client-side function.

For many Ajax developers, who are already doing great things with JavaScript, HTML, and CSS on the browser, the prospects of doing everything that way, even on the server side, is very appealing.

But Java, PHP, Ruby, and other server-side platforms have tremendous established bases, strong developer communities, and powerful tools to make them compelling environments for back-end development. And indeed the vast majority of modern web applications use one of these platforms for their back-end layer.

No.

Jaxer and GWT both address the question of how to unify the development paradigms across client and server. But they take very different approaches, at least to the UI part of web applications. GWT appeals to developers who would rather not write HTML or JavaScript at all, and instead have it generated automatically from their Java code. With GWT the developer writes server Java code for to describe the UI, and GWT autogenerates it.

Getting and running Jaxer is a snap:

1. Either grab a copy of the latest Aptana Studio, and click the Jaxer button to turn it on, or...
2. Download the self-contained Jaxer package for your operating system and fire it up —