XAMJ: Java XML UI & RIA Markup Language

Note: The XAMJ language effort is no longer active, and this page remains here for historical purposes only. You can find the latest source code of this sub-effort in CVS module XAMJ_Project/XAMJ_Extension. You might want to check out what we're doing with JavaFX.

XAMJ is an XML UI and text markup language tightly integraded with Java. XAMJ applications/pages may be deployed over HTTP (like HTML or Java Webstart) or locally on a user's PC. We have an open-source browser/platform for the deployment of XAMJ content, named Warrior (download), itself written in XAMJ.

The Warrior platform can currently be used (1) to deploy XAMJ apps over HTTP similarly to Java Webstart, (2) to launch standalone XAMJ apps, (3) as an XML UI API, and (4) as a browser for new content types, including other Java-based XML UI languages.

XAMJ allows embedding Java code in several types of scriptlets, much like JSP, except on the client side (with security restrictions.) That is, a XAMJ document is translated into a Java class, called a clientlet. We believe this solution is considerably superior to using a scripting language such as Javascript.

There is no need to pre-compile or package XAMJ code. Testing your changes involves simply modifying the source code and running it, much like trying out changes to an HTML page. Additionally, we provide a way to link XAMJ apps from HTML which is similar to the way you link JAR files using JNLP, except we make it simple. (Our examples use that.)

XAMJ UI markup is a lot more compact than equivalent Swing or SWT code. XML UI languages in general are considered Rapid Application Development (RAD) tools for this very reason.

XAMJ apps can also be standalone. In Windows you can simply double-click a .xamj file. Compilation is on-demand and cached, so it has the major benefits of an interpreted language, without being one.

XAMJ documents (and clientlets in general) have access to a capability we call managed stores. These are small file systems with quota restrictions accessible securely by documents served over HTTP.

A XAMJ app can link another app much the same way HTML pages link one another. For example, an app could have a Forum menu-item with an href attribute that launches a separate specialized app, potentially hosted by a third party. (Some of our examples link each other this way.) We don't expect different brandings to be as much of a concern as it is with HTML pages.

To get a better idea of where XAMJ technology fits in relation to other client platforms, see the following table which breaks down how it compares in several key areas to two well-known technologies: (1) HTML/Javascript browsers, which are thin client platforms, and (2) Java Webstart, which is more of a thick client platform.

HTML & Javascript

JNLP (Webstart)

XAMJ (Warrior)

Syntax

HTML syntax is known to be brittle, prone to ambiguities, not very suitable for verification, and hard to scrape. XHTML intends to fix that (but XHTML is not available in IE as of this writing.) Javascript is not type-safe, not really object-oriented, error prone, and difficult to debug.

The Java language is quite type-safe, even more so now with generics. It is object oriented and incorporates threading, synchronization and other important features as part of the language.

XAMJ syntax is strict XML. XAMJ can embed Java code which is compiled as the document is processed. Any errors in the document processing phase are shown right away. Errors that occur during event processing are logged. (The Warrior platform now provides a console for standard output.)

Skills Needed

Some basic HTML may be written by virtually anyone. Web designers without much knowledge of programming can create amazing things with it. More advanced uses of Javascript (AJAX) do require considerable knowledge or programming and skill.

JNLP of course requires knowledge of Java and object-oriented programming.

XAMJ markup is not that different to HTML. We expect it to be simple enough for web designers to be able to do a lot with it without getting into Java programming.

Processing & Packaging

An HTML document may be easily made available on the web. No compilation or packaging are necessary. The document is parsed by a browser and rendered.

Java program source code consists of .java files which need to be converted to .class files, which are then packaged into .jar files. A JNLP file contains meta information in XML about the program and how to locate it.

A XAMJ document is automatically compiled into a special class called a clientlet, which is cached. No in-advance compilation or packaging are necessary.

GUI Capabilities

Limited to a large extent, although there is much you can do by combining images and significant scripting (AJAX) code. This does make it pretty high-bandwidth for relatively simple things. Vector graphics are not really doable.

It provides the AWT and Swing frameworks. Swing is quite complete, and is sometimes criticized for being over-engineered. The competing SWT framework is considered better by many.

Although still evolving, XAMJ has a DOM which includes many common widgets such as trees, tabs, etc. XAMJ is designed so that it is feasible to implement its DOM interfaces with alternative GUI frameworks, despite the fact that Warrior is implemented as a layer around Swing. XAMJ GUI code is generally a lot more compact and simple than Java GUI code.

Text Markup Capabilities

Fairly extensive, but not perfect.

Available to the extent that an HTML component or an external library is used. But HTML support in Java is not fully up to standard as of this writing.

XAMJ text markup is still at an early stage, but we expect to improve it considerably and add capabilities not available in HTML. XAMJ markup, again, is very similar to HTML.

Other Capabilities

The API library available to Javascript is fairly small. There are scripts available on the web in source form which may be incorportated in a page.

The shipped library is enormous. The number and complexity of libraries available thru third parties and open source projects is also very extensive. Some of these capabilities may not be accessible due to security.

XAMJ has access to the Java library. XAMJ provides a way to load external JAR files as well. Security restrictions also apply to XAMJ apps deployed remotely.

Security

Most security in HTML is achieved due to lack of capability. There is no direct access to files for example. That has to be done thru Java applets. Even so, HTML browsers are generally plagued by security problems.

Java implements a security sandbox with policies and permissions.

Warrior leverages the Java security architecture. It installs a security policy applied depending on where the application is launched from. We also expect to identify possible attack scenarios and publish how they are dealt with. The open source community is invited to review the source code for security holes and give feedback.

Local Storage

There is no access to the client file system in HTML/Javascript except thru plugins such as Java applets. A browser can, however, save small named pieces of information called cookies.

A Java program served over HTTP cannot normally access the client file system, unless the code is signed. It can, however, save muffins which are more flexible than HTTP cookies, and are identified by URIs.

A XAMJ (0.93+) engine must provide a managed store per host, restricted by a size quota. This is basically a small file system that code served over HTTP can safely access on the user's computer.

The Warrior Platform is free and open source. The source code is available in CVS (module XAMJ_Project) and each version tagged. It is released under the terms of the LGPL License.