Sunday, November 23, 2008

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.

Saturday, November 8, 2008

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.




Wednesday, October 29, 2008

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...

Tuesday, October 28, 2008

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.

Tuesday, October 21, 2008

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.

Friday, October 10, 2008

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.

Thursday, October 9, 2008

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...

Tuesday, October 7, 2008

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.

Sunday, October 5, 2008

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.

Tuesday, September 30, 2008

API-based queries

I'm a big fan of API-based queries. Even though I really appreciate query languages (e.g. SQL), the impedance mismatch of using them inside your favorite programming language is too high, even more when you're dealing with dynamically generated queries. So much string manipulation is really error-prone.

So I really like approaches such as Lucene's or Hibernate Criteria API. However, API-based approaches are normally low-priority (above all when dealing with SQL), so standards like JPA doesn't even have such an API and in Hibernate it is far more limiting than HQL, and issues like this are real showstoppers.

Update: typo

Sunday, September 7, 2008

Types and Programming Languages

Putting my money where my mouth is, in my last order to amazon (dollar is still cheap) I got Pierce's Types and Programming Languages, after having it in my wish list for a long time.

I expect it to be a long read, as it is pretty long and dense. In any case, even though it is quite academical, I'm sure it'll be eye-opening. Stay tuned.

Refactoring lucis...

These days I've been spending a little time refactoring lucis. In these early stages of development, the public API is being continuosly changing, as I look for better ways to provide the intended service.

Through this process, I've faced what I think is one of the most difficult problems in computer science: naming things.

In this case, there are some classes that deserve names already used by Lucene (Query, Searcher, etc.), and many source files (from users of lucis) may reference both Lucene's and Lucis' classes. Even though this is not a problem, I don't like fully-qualified names, so I've had some thesaurus time :) 

Thursday, August 28, 2008

Neil Gafter is leaving Google...

Via twitter. It will be interesting to know about his new gig...

Update: New employer revealed...

Thursday, May 22, 2008

On breaking Java

After Ola Bini's post on a list of features he would like to see in a compatibility-breaking version of Java, everyone seems to have his own, so here's mine:
  • No primitives.
  • Closures and arrow (function) types. This would also open the door to using methods as values and method names as first-class identifiers.
  • Non-nullable types by default. Use of something like Scala's Option.
  • Better support (syntactic sugar, friendlier APIs) for immutable types (and maybe explicit pure functions?).
  • Reified generics, with some improvements as well.
And the most important thing for me would be to clean up the APIs, removing obsolete ones and retrofitting the others to the new features.

Sunday, May 18, 2008

Feeding the Rumor Mill

A good way to generate expectations :)

I, for one, would really like to see zfs on linux.

Friday, May 16, 2008

On Types and Programming Languages

Programming languages and type systems are two fascinating subjects inside computer science, and there are plenty of sites devoted to them. They are great fields of research for academics (and the industry) and source of endless debate in the open source world and the blogosphere.

This week, static vs dynamic typing has been brought again to the front page by this (lengthy as usual) post by Steve Yegge. If you go through the transcript of this pretty interesting presentation you'll see that in the end,  he really focuses on dynamic just-in-time compilation techniques, which are also available for statically typed languages (provided they are run through some kind of vm, such as the hotspot java virtual machine). Anyway, after (or in reaction to) this post a great amount of content in the subject has flourished.

As a debate in itself, it is really interesting because it's a good way to  get introduced to new advances in both camps (and to discover the past, there many things that sound new but were invented decades ago). And in my opinion, it's endless in nature, as the only absolute truth may be that there is no language (nor type system) that fits best in all situations.

So in the end, in many cases is just a matter of personal preference. And even though I really get the value (and in many cases even the need) of dynamically-typed languages I have some personal bias towards static typing (I'm nearer to Cédric's position).

Ironically, I've found myself limited many times by the type system of the programming language at hand (mostly Java) but that has only increased my interest in learning the possibilities provided by languages with more expressive type systems (ML family, Haskell, Scala...).



Thursday, May 8, 2008

SpringSource App Platform and evolution...


Some days-old news, but interesting anyway. Worth a deeper look.

I think is a concept that many people were thinking about after seeing some big real-word osgi deployments, but it had to be done. Credit when credit is due.

It's hard to balance the need to maintain compatibility (and investment) and the need to keep going forward, and sometimes we all have to deal with some breakage.

Depending on what gets finally goes into Java 7 and the end of the "modularity wars" we may see more interesting steps.

Anyway, there's been some controversy regarding the license. Although I'm sure there's not absolute truth in any camp, if you are a very strong advocate of one position and suddenly (and in a particular issue) change, at least you lose a bit of credibility.

Back to the evolution issues, even though many people argue that the way to innovation in Java (the platform) is other languages on the JVM (scala, groovy, jruby) I think it's high time to start breaking some ties with the past, but, is it worth the effort?....  


Tuesday, May 6, 2008

First Post

Test. Hello world...

This seems to be quite usual content for a first blog entry. In my case it's just going to be some administrivia :)

As of now, I'm willing to post all my entries in (my sort of) English, but just in case, posts in English will be tagged "en" and posts in Spanish "es".

Also, entries as this one, related to the blog itself will be tagged "meta", so I could have just chosen Metapost as the title of this post, but it was already taken :)