Is it time to go stackless?

As a follow-up on Guy Steele's post on tail recursion referenced on my last one and Cook's paper, there's another interesting post by Gilad Bracha that made me wonder: is it time to go stackless?

The stack, as an optimization for call convention is deeply rooted into greatly extended instruction sets. But now, with the amounts of RAM and CPU power available and the really cheap short-lived object allocation time in modern VMs, I think we could afford it, at least for high level languages.

Back in my Python days, I remember Stackless Python, an implementation of this programming language with support for continuations, generators and coroutines.

And this would be only the beginning...

Tail calls in OOLs

Yesterday's paper is also related to a very interesting post by Guy L. Steele Jr. on the need of tail calls on object-oriented languages. A rather polemic issue with strong proponents (such as Guy) and detractors, like Guido Van Rossum, Python's creator.

I'm sure more interesting contributions will follow.

Readings on Dec 6th 2009

Today's reading has been "On Understanding Data Abstraction, Revisited" by William R. Cook. It has really been an eye-opener on the differences between abstract data types and objects, and it have helped me  understand the implication of the different approaches taken by different programming languages.

Highly recommended.

Lucene 2.9.0

A few weeks ago Lucene 2.9.0 was released. The list of changes is impressive, and it's certainly an interim release paving the way to release 3.0, where I suppose many of the now deprecated methods will start to disappear.

One of the most interesting changes for me is LUCENE-1382, which will greatly simplify checkpoint management in lucis.

Looking forward to 3.0.

Functional dependencies

Regarding papers, yesterday's read was Type Classes with Functional Dependencies by Mark P. Jones.

Quite interesting.

CUFP 2009 Keynote

Bryan O’Sullivan is one of the authors of the book Real World Haskell, and he's given the keynote at CUFP 2009.

CUFP 2009 Keynote - Real World Haskell

View more documents from Bryan O’Sullivan.

I really liked the presentation.

Papers

Over the last years I've become an avid reader of papers. As the time goes by, I start to have heaps of PDF files scattered through multiple files and computers, unable to find anything.

A few years ago I read in Ars Technica about Papers, a software package that seemed to fulfill all my paper archiving needs :). However, it wasn't until last month that I gave it a try and I only regret not having donde so earlier. Its matching capabilities, search engine and spotlight integration are really wonderful. It is really the iTunes of academic papers.

Highly recommended.

Counting and Grouping Queries in Lucene

When using a Lucene index to look up some information you have access to some querying facilities not found in other kind of repositories. However, in a classical trade-off, you lose some features such as the aggregate queries easily performed in relational databases.

Anyway, if you need to perform this kind of operations, they may be easily implemented using hit collectors. So, I've included in lucis two simple operations, counting and grouping results:

The LucisQuery object is used to decouple index control policy (when to open and close it, etc) from the queries themselves.

The counting query just needs the Lucene query to perform and the (optional) filter to apply. The result holds the number of documents found and the time the query needed.

For the grouping query you must provide the list of field names you want to group by (in order) and the query result is the same that the counting query plus the root group (the one corresponding to the first field name), where a group is something like (partial API showed, see the source):

So, for each collected value of the provided field you get a child group which itself contains the groups representing the nested fields. The number of hits in a group may not be equal to the sum of the hits in the children groups if any of the fields is multivalued.

Pointcut expressions for stereotypes

Some of the new additions to Spring in version 2.5 are annotation-driven configuration, classpath scanning for managed components and @AspectJ support for AOP. These features can gretly reduce the amount of XML needed to configure your application context.

Together with classpath scanning came stereotypes, which, as the reference documentation states, make ideal targets for pointcuts. In putting this idea (stereotype as pointcut target) you may find two different candidate expressions in the documentation (the Service stereotype is used as an example): @target(org.springframework.stereotype.Service) and @within(org.springframework.stereotype.Service) with no clear differentiation between them.

However, some of the differences started to show up as Spring auto-proxying mechanism started to try creating proxies for classes that had no stereotype and were not advised in any other way. After a non-immediate web-searching session, the real problem stood up: if you use @target every class is proxied just in case a new subclass with the annotation is introduced. Even though the issue is marked as resolved, I have suffered it in 2.5.6SEC01.

So, in the meantime, just use @within.

'This' type and Covariant builders

When designing your own APIs, either by using interfaces or class hierarchies, you usually find the need to reference the type of the actual implementacion of the interface or class you are writing. This is an actual problem, and there's even a proposal in Project Coin (small language changes for Java 7) to deal with it.

One of this cases, and the one the rest of this post is focused on, is using the 'This' type as the return type of some methods. This is particularly useful for method chaining in fluent interfaces.

Up until Java 5, and the introduction of covariant return types, it was impossible to deal with this issue, which led to frequent casting. But even with Java 5+, the solution is based in manually overriding every method in the subclass (or subinterface) changing the return type to the desired subtype, calling super and returning this.

So, I have checked-in a partial solution to this issue. The type signature of the Type class This<T extends This<T>> (equivalent to that of the Enum class) allows the implementation type to be referenced inside the class, and its value obtained by calling thisValue. But not only the final implementation type, but also some siblings in the hierarchy (as showed in the tests), as the Java type system cannot guarantee this.

That's the reason for the validation in the constructor of This, the reason it is an abstract class instead of an interface, and one of the many reasons it is only a partial soluction.

One application of the This type is for builders (see the builder pattern and item 2 in Effective Java 2nd Ed.). If your builder is part of a hierarchy you are faced with the problem described in this post, so I've also included a base class for them, the covariant builder.

Spring and REST

Here's a post on REST Support in Spring 3.0 by Arjen Poustma. I have mixed feelings about this. On the one side I'd prefer better integration with JAX-RS in general and Jersey in particular. On the other side, I appreciate choice and the closer integration.

 

The MapMaker

Google Collections 0.9 is out, and this class is really cool. I hope to make good use of it really soon...

New packaging in Hibernate 3.3

As the new packaging in version 3.3 of Hibernate changes a bit the dependencies game, I post this pointer just for reference...

Binding to values

In a Guice module, binding a class to a specific value is directly supported. How about Spring? You have to provide a FactoryBean.

TestNG

I had read about TestNG, including the book, and even played a little bit with it. But, until today, I had never set it up as the testing framework in a project instead of JUnit.

Why have I taken this step? Well, I have felt the need many times to keep state between test methods to simplify them (and if you add dependent methods, also in TestNG, in order to chain them), even though I understand JUnit's reasons for not providing this functionality.

So, TestNG has earned itself another "testing" round :).

 

Living on the edge...

As predicted by Murphy's Law, if you need some feature (or a critical bug solved) from a third-party library or framework, it'll be planned for the next version.

I faced this truth again a few weeks ago. I was looking at Guice for some specific dependency injection needs... and type converters where planned for 2.0...

A Domain Driven Design snippet

This post in my reading list reminded me of Domain Driven Design (see the book). I've always liked the idea of strong Domain Models that lead to better encapsulation and more information hiding.

What's the problem, then?. For many (even CRUD) applications much business logic involves non-trivial repository access. So, you need your bussiness objects have a reference to the repository. This should not be a problem for your favorite dependency injection engine.

At this point your favorite ORM tool chimes in, taking control of the lifecyle of your domain objects... Well, there are some AOP-based solutions, but I don't see them as long-term general solution yet.

Null-default and Null-safe operators

Today I've been having a look at Stephen Colebourne's proposal for null-handling in Java 7 (see this post for a summary).

I really like this proposal:

• It is only syntax sugar, like many of the changes introduced in Java 5.
• It really helps to reduce boilerplate code.

The main drawback I see is that heavily chained uses of the null-safe invocation operator may lead to some debugging knightmares (which invocation returned null?) unless some support is added to IDEs.