Applying the new programming library ATCT to asynchronous messaging and Java scripting can add some interesting new features to core Java. Learn how it works and how it can simplify your job.

by Laurent Michalkovic

May 27, 2003

Page 3 of 3

Under the ATCT Hood
Java owes part of its success to some key features, including:

Reflection: the ability to discover at run-time the true nature of an object

Serialization: the ability to store the complete state of an object's instance and restore it at a later date.

A very simple and consistent multithreading programming modeleven on platforms without native support for threadsbased on the Thread class

Unlike many of the other standard Java objects, Sun unfortunately did not make the Thread class serializable, preventing developers from saving the JVM's execution context.

ATCT provides an elegant and powerful solution to the continuation and serialization problems. Its ATCThread class contains a complete bytecode interpreter with its own private execution context. This solution is pure Java and portable across virtual machines. Effectively working as a secondary interpreter, ATCThread uses reflection to draw on the JVM for much of its core services while supplementing it with the following:

Method discrimination, allowing programmers to decide which interpreter should execute any given method

The ability to force a context switch between interpreters at will from anywhere in the code

Tail call elimination, support for shortcutting the return path from a method when it is immediately followed by a return instruction inside the body of the calling method

ATCThread provides the following methods to completely control the execution of bytecode in the secondary interpreter:

start(): starts the execution of a method in the secondary interpreter, using an internal Thread

suspend(): pauses the secondary interpreter. While it is in that suspended state, a developer can serialize the interpreter to a file and store it indefinitely.

resume(): resumes execution of the bytecode in the secondary interpreter

ATCT offers another way to momentarily suspend the ATCThread interpreter: declare a method as throwing an ATCSignal exception. When the ATCT interpreter runs into an invocation of that method, it simply ignores the method body and returns control to the native interpreter. Called from the native JVM interpreter, the same method body would be executed normally. Similarly, ATCThread uses the AISignal exception to discriminate the code that it should execute.

This tried and tested code-marking technique is already familiar to EJB and RMI developers. If it is not flexible enough for your situation, the ATCT API lets you implement custom discrimination heuristics. The upcoming Java 1.5 will offer an interesting alternative scheme with its new declarative programming style.

ATCT Adds Features to Java
Velare Technologies is adding some interesting new features to core Java with ATCT. The library simplifies the programmer's job in the two areas reviewed in the previous sections. Other possible uses include game scripting engines (using continuation), a simple failover scheme, grid computing, and the creation of some simple agent frameworks where an ATCThread could be sent across the network and deserialized on a different JVM.

Laurent Michalkovic is an independent technology consultant based in Vancouver, British-Columbia. He has over 15 years of experience designing and building complex IT solutions, and has been in a committed but non-exclusive relationship with Java since beta 1. E-mail him at laurent_m@hotmail.com.