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.

At last...

I was waiting for this. Projects uploaded to maven central must have all its references satisfied by maven central itself. This is sometimes a double-edged sword...

Thread-safe simple lifecycle (part 2)

After last post, there are some issues that remain open:

• Do clients need to know about transient states? After all, in our multithreaded environment we only want to know if the service provided by the active object is ready to be used or not, regardless of which thread's start command did the trick.
• What happens if we stop the object while there are in-flight requests that depend on the ON state (such as a resource disposed after a stop command)? Can we provide deterministic behaviors for these cases? Can we provide them minimizing synchronized regions and contention?

Stay tuned.

Thread-safe simple lifecycle.

The subject today is not rocket science,  but it's been common enough through the years to deserve a post :). The problem is as follows: we have and object with a very simple lifecycle (on and off) and we need (or want) the status-changing methods (start and stop) to be thread-safe.

Of course, we can just make start and stop synchronized but, can we do better? Ok, let's polish our list of desired features:

• We want a generic solution. We only want to write the transition code (starting up and shutting down) without worrying about thread-safety, getting it for free from the solution.
• We want to minimize synchronization, and ideally avoid it.
• If we can't avoid synchronization, we forbid calling alien methods from synchronized regions (to avoid unforeseen problems in the future).

So, I've checked-in a possible solution. It avoids synchronization by adding some transient states and using AtomicReference (the java.util.concurrent.atomic package contains equivalent classes for different types). More specifically, the solution is based on the compareAndSet method, which besides the properties described in the documentation, has the added benefit of being idempotent, a property that really simplifies reasoning in concurrent and distributed systems, at very different levels of abstraction.

Update: Changed svn links to tagged version.