Asynchronous transitions for Active Objects

I've added support for asynchronous transitions in ActiveObjectSupport (see parts 1, 2 and 3 in the series).

The asynchronous versions share the same logic of the synchronous ones. The preconditions are checked in the calling thread, the state change to a transient state is also done in the calling thread (as it was previously shown it's just an update to an atomic reference) and the transition is performed in a background thread, including waiting for pending requests to finish.

Why did I add this feature now? Well, I'll need it for the next iteration of lucis.

Thread-safe simple lifecycle (part 3)

In parts parts one and two of these mini-series, we started showing how going multi-thread could affect the simplest lifecycle of what we called and active object. In the end, what we have is a set of open questions, including (some of them were presented in previous posts):

• What happens if you try to start the object and some other thread have previously done so?
• What happens if several threads try to stop the object at the same time?
• What happens if you try to stop the object when there are in-flight requests? Do we wait for them to finish? Do we stop and let them crash?

And the answer to all these questions is the same: it depends. It depends on the semantics of each particular object, so we can't provide a solutions suitable for everyone, every time. But this doesn't mean we can't do anything. I've checked in a new solution. Some of the highlights include:

• The lifecycle interface is gone. As we have shown different problems need different semantics and thus, a different interface. Instead, we have a support class.
• Though externally the same fixed-set of states is kept (implemented as an enumerated type), internally an infinite set of states is used, so that we can keep track of in-flight requests.
• No synchronization is used, and state changes are performed using atomic references. Client-provided transition code is guaranteed to be run by just one thread without holding any locks.
• No standard semantics are enforced. Instead, the support class provides methods so that you can build your own. Eg, if you call a method to start or stop the object while the transition is being performed in another thread an exception is thrown. However you can catch this exception and use the provided methods to wait for the object to reach a permanent exception to implement different semantics.

Maven deploy to sourceforge

Recently some changes have been made in sourceforge. Basically, previously somewhat unlimited shell access has been removed and now file upload must be done through web.sourceforge.net using username,projectname as the login. This service supports SCP, SFTP and rsync though SSH.

However, I haven't been able to get maven to deploy to sourceforge using these new settings, and I haven't found a solution yet. As a workaround you can issue:

ssh username,projectname@shell.sf.net create

and you will granted (temporal) shell access so you can still use your old-style scp deploys to shell.sf.net. So, you have to (manually) request this shell access before performing your deploy.

This change also affects maven site deploying. When deploying your maven site through SSH, maven uploads a compressed file containing your site and then remotely uncompresses it. However, web.sourceforge.net does not allow remote command execution, so maven is unable to uncompress your site. Fortunately, the same workaround described here applies.

Weird Eclipse Error...

...and only one Google result for 

"the eclipse executable launcher was unable to find its companion" os x

so I'd better keep a pointer to the solution here...

The Properties Pattern

Last monday Steve published another lengthy post on what he called The Universal Design Pattern. As I read through it, it reminded me of my personal walk through some of the issues described there. It was in the JDK 1.1 days, when the JavaBeans specification had just come out. The JavaBeans event system identified the properties as strings, which led me to try what Steve calls the Properties Pattern in a never-finished project that I used a test-bed int the late 90's: a Java port of a Monopoly-like game I wrote in C++ back in 1994 . It was an interesting experiment, and I had to deal with many of the issues described in Steve's post. Anyway working with string-based properties in a language like Java is quite uncomfortable to say the least.

However, this does not mean that you need a dynamic or a prototype-based language to enjoy the advantages of this approach. In the end, each property has some pieces of metadata that could encapsulated into... a type. You just have to add an API that makes it convenient to deal with this kind of properties. Frameworks such as Guice have really raised the bar on what can be done getting the most out of the Java type system and the levels of type-safety that can be achieved.

Reflective Instantiation in GWT

Note to self: A couple of links on how to achieve reflective instantiation on GWT using generators. The feature set of this framework still amazes me.

Worlds

Via Lambda the Ultimate I found "Worlds: Controlling the scope of side-effects". With Alan Kay as one of the authors you can assume it's worth reading. And what is really worth visiting is the environment the prototype implementation is built on.

It has really reminded me of Software Transactional Memory and there are several comments in the same line. I've read some of the work by Simon Peyton Jones on the subject, mainly related to Haskell, and I consider it an interesting approach that could simplify many tasks contributing to an increase in quality in many types of applications. 

And as this paper shows,  you don't need a pure functional programming language to play with this kind of concepts, but I really think a type system that, at least, make the existance (or not) of side-effects explicit is really helpful.