Those who attend our forums or subscribe to release feeds have already noticed that both stable and development branches saw new releases two days ago. Users of 1.1-M1 should definitely seek upgrade. Sourceforge has it all.
Aranea Continuations project supports waiting on Swing and Aranea events by introducing high-level API over the JavaFlow library, hiding the mechanics of continuations behind an annotation, blocking calls and an instrumentation agent. Download from SourceForge or read the reference.
Continuations is one of the most hip and misused terms in Java community. Popularized by Geert Bevin and RIFE framework they allow to wait for event to happen and resume the method execution from the point on. A common point of comparison is the readln() DOS function that waited for user to input before resuming. In Java we are interested in waiting on events like user clicking a button.
Support for continuations in generic Java has been available for some time via the JavaFlow library. However their API was relatively low-level and clumsy in day-to-day development. As a part of Aranea Continuations project we built a higher level API on top of it, which can be illustrated by the following Swing example:
class BlockingSwingExample extends JPanel {
//Method with continuations
@Resumable
public void init() {
JButton button = new JButton("Click on me!");
add(button);
updateUI();
for (int i = 1; i <= 10; i++) {
SwingBlockingUtil.waitForOneAction(button);
System.out.println("You have clicked me " + i);
}
System.exit(0);
}
//Swing boilerplate
public static void main(String[] args) {
BlockingSwingExample panel =
new BlockingSwingExample();
JFrame frame = new JFrame();
frame.add(panel);
frame.setVisible(true);
panel.init();
}
}
The important part of the Aranea Continuations API is the @Resumable annotation and SwingBlockingUtil.waitForOneAction(button) call. The first one tells that the current method can be resumed later while the second will wait until the listener is called. The code will wait till user clicks the button exactly ten times and then will exit (the example is available with distribution by running ant run-swing-example).
To make the example run we need to instrument the classes bytecode. In addition to the preprocessing supported by JavaFlow we have implemented support for Java Instrumentation API, so it becomes as easy as registering an instrumentation agent:
java -javaagent:aranea-blocking.jar=example example.BlockingSwingExample
To limit preprocessing the agent receives a comma-separated list of the application packages as a argument (in this case the example package).
Aranea Continuations provide support for waiting for Aranea MVC events same way as in Swing. The core API here is the AraneaBlockingUtil. However in addition to events we provide support for invoking flows and waiting for the return value:
@Resumable
String askForName() {
String result =
AraneaBlockingUtil.call(
getFlowCtx(),
new DialogWidget("Please enter your name:"));
return result;
}
This will display the user a separate page with an input box and return the value of the text box when user submits the form.
Looking under the hood blocking calls are implemented using a simple call/cc semantics:
static void waitForOneAction(final AbstractButton button) {
BlockingUtil.call(new IndirectCallable() {
void call(final ReturnContext returnCtx) {
final ActionListener[] aListener = new ActionListener[1];
aListener[0] = new ActionListener() {
public void actionPerformed(ActionEvent e) {
button.removeActionListener(aListener[0]);
returnCtx.returnWith(null);
}
};
button.addActionListener(aListener[0]);
}
});
}
ReturnContext represents the current continuation that can be called to return from method once or several times:
public interface ReturnContext {
void returnWith(Object result);
void failWith(Throwable t);
}
Using that it is trivial to add support for other events or actions. In fact we only implemented Swing blocking API because we realized how easy it is on top of the existing API.
Nothing comes for free and this is doubly so for bytecode modification. JavaFlow will definitely add a performance penalty to your application. However you should consider that it will almost exclusively add CPU consumption and will not stress IO or memory. This means that in most projects the impact will not be considerable or possibly even noticeable. This goes specially to desktop Swing applications, which are highly unlikely to be CPU-bound. Of course one should stress-test the application to make sure what the impact is in your environment.
The first release is available from SourceForge with a (brief) reference also available. We will continue to improve the project and plan to release as much of changes upstream as we can. We are also looking for contributions supporting blocking calls in other frameworks (like SWT). We would like to express our gratitude to Rein Raudjärv for developing the project and to Oleg Mürk for the original idea.
This year we are taking a trip to Barcelona by generous invitation of TheServerSide folks. The talk is Step-by-Step Legacy Migration with Aranea, which is an approach to use the Aranea Integration to migrate web applications from older web frameworks (and not to Aranea, but to any newer framework/technology). We are planning to announce the approach in full at the symposium, so be sure to register while there are still places 
Also releases of several subprojects and Aranea 1.1 final are expected to be done by the time of the symposium, so that you could take immediate advantage of the new features.
It is our great pleasure to announce the release of the first milestone in the 1.1 development branch. This milestone includes following improvements:
InputData and OutputData have been removed. process() method was removed from the Widget class since it broke in some cases implicit assumptions about the Object-Oriented encapsulation. The component model is now truly OO without any surprises and objects can be used without any restrictions.OutputData attributes and forbidding JSP tags to depend on other component tag context entries. This both allows the partial render support and true encapsulation, laying ground for the integration project.The current reference manual is out of date and we do not yet provide a migration guide, so we suggest to wait until the next milestone before upgrading. However a comprehensive API changelog is available here. Download from SourceForge.
As one would expect from ‘friday-the-thirteenth’ release, 1.0.7 included an accidental change of form list behavior. This caused NPEs in use cases which were legal before 1.0.7. In new release, old behavior is back. We are sorry for any inconvenience!
Another ‘friday-the-thirteenth’ stable branch update is available, including the brand-new TreeWidget that was backported from development branch. It is easy to use and very flexible.
Some minor issues were also fixed. Next week we hope to bring you the first milestone of Aranea 1.1
Thanks to the great guys behind JavaPolis the “Object-Oriented Web Application Development” talk is up online on Parleys.com. Those of you who missed us at JavaPolis can now get a good idea what the talk was about (and hopefully enjoy it).
Includes support for asynchronous form updates, meaning that values in forms living in one ‘session thread’ can now be easily modified from other ‘session thread’ or widget’s action listener; no more need to do awkward method calls for modified values to actually take effect. Also, memory based list implementation makes fewer calls to database.
Download from the usual place, full changelog here.
Stable update of Aranea was rolled out last Friday and is available from the usual place. See changelog and note that tags used by example applications have moved to their own separate TLD namespace; previously examples mixed standard tags (conventional namespace prefix ‘ui’) with template tags (now have namespace prefix ‘tui’) which got rather confusing for first-time users.
One of the main additions is a “blank” example application, which can be used to kickoff new projects easier.
Some problems with asynchronous modification of forms (from widget actions or session threads) have surfaced; we will address these in next update of stable branch.
Although we have been silent for the last month or so it was not for the lack of activity. First of all, we are working hard on the integration and have setup both a separate subproject and a ChangeLogic project, so you can track our progress right away. The anonymous SVN access is available through HTTP: http://svn.araneaframework.org/repos/aranea-integration/branches/latest/. The project is still a bit raw and will only run in Sun Application Server (this only concerns JSF examples).
Secondly, we are working on the step-by-step legacy migration and are starting with first projects to be done this way. We will write about the concept and the success stories as soon as we have the latter.
Thirdly, we are working on cleaning up the Aranea request-response model, to allow for easier asynchronous programming as well as localized rendering. This allows for instance to access widgets through JavaScript and render only one widget at a time. This was partially done to support our new TreeWidget, which is an all-AJAX tree view control.
Finally we have a lot of more-or-less innovative improvements that are worked on by both our team and other Webmedia workers. Most of them are done as some kind of University theses and we expect them to be finished around April. You can read about them (briefly) on Jevgeni’s university homepage.
This all is a LOT of work to be done in a little time, which explains the lack of updates on our blog. But expect a lot of good news as well as some unexpected surprises to come up soon.