I am glad that you pointed out how to improve the code. I'll definitely consider generifying the relevant classes, as long as the tradeoff between strict syntax and readability are balanced. The danger that the code poses are not as grave as you apparently perceive it. We all had to deal with Java lists and subsequent unsafe typecasts for the longest time. If an unchecked warning is a bug to you then I'd be curious to see, how you introduce Java Generics into a large codebase from code < J2SE5.
As for the usefulness of Amber you and I differ in our expectations. To me a framework is useful if it lets me do the things I want to do with comparable ease. Your claim that the code example invalidates the approach in general doesn't make sense to me -- I showed how roundtripping can be avoided, if that is a concern. That this is not provided by the framework as an automatic feature has also been discussed in the article. The important aspect is that you can construct your object model based on what the database returns. The fact that Amber does not dictate an object model but lets you decide how to do it is a feature -- well, at least to us. Finally, code that is easy to use and to maintain is often more valuable than highly optimized code. You will clearly not use the library, fine, but I can assure you that it works very well for us. Our customers have not complained about performance at all. Oh, and, you might have noticed that I never claimed that Amber is an O/R framework. There is a conceptual difference, hence the title.