Women in Technology

Hear us Roar

  Lightweight R/O Mapping
Subject:   Generics and Roundtrips
Date:   2005-12-12 10:11:37
From:   SeanReilly
Response to: Generics and Roundtrips

So, when I wrote that

ArrayList<T> list = reader.executeCreateBeanList( "..." );

will have the compiler issue a warning, I am right.

Ahem. While technically true that you are able to understand why the compiler has an issue with your code, that doesn't change the fact that you weren't correctly dealing with the issue.

From your article:

The compiler will issue a warning here, since the reader only knows at runtime what kind of class it is going to create. Because of type erasure in the generics implementation of J2SE 5.0, it is not possible to safely cast the result. And, sadly, it is also not possible to write the BeanReader class as BeanReader<Jedi> for the same reason. In short, using Java reflection and generics don't mix.

The original article claims that this kind of operation is "not possible". I provided you with a code example that proves that it is, if you use the correct syntax. You then replied that you were correct in describing the original compiler warning. This doesn't have much to do with the very relevant fact that the framework and example use the wrong syntax.

you've raised a philosophical question: Suppose your code works, I'd agree that it is explicit, but is it more concise? Considering type erasure and the fact that I need T.class to dynamically construct the required object (say, of type Jedi) would it be better to have a generified class BeanReader<Class<T>> to get rid of the unchecked type warning even though this information cannot be accessed for reflection? It might be nice to read, but seems cumbersome to code, wouldn't you say?

Your philosophical objections to the correct syntax are between you and the people at Sun responsible for Java language syntax. Until such time as the offical language spec changes to accomodate your preference, choosing convenient syntax over over correct syntax is a bug. That is precisely why the compiler warns you about it.

You are
right: In the example you brought up, the code I showed would
perform poorly. What I did not show is that Amber supports you,
if you wanted to join the Jedis and the Fighters on the database return a result set that contains Jedis (redundantly in their respective columns) and their Fighters (individually). You'd then create a class that holds a Jedi plus one single Fighter, load a list of this class (1 database query) and wrap it in mapper code where you'd extract the Jedis with their Fighter list.

Ah, I see. By "supports you", you really mean "allows you to do all of the work yourself". The primary requirement of an O/R framework is to convert relations into object hierarchies (hence the name). A framework that doesn't do this is basically useless. All this code provides is the simple ability to use reflection to unmarshall a simple result set into a simple object (or list of objects), but not a hierarchy. In other words, this is something that one could eventually use to build an O/R framework, but it isn't one itself.

This begs the question, why would you want to load 10000 Jedis into the client? If the user will filter them, this should be done in the database, right?

10000 was used as an example to illustrate the ridiculous absurdity of the example's performance. The code is still bad even if it returns only a half dozen results, but it is less obvious to the untrained eye.

Full Threads Newest First

Showing messages 1 through 2 of 2.

  • Generics and Roundtrips
    2005-12-13 23:26:51  Norbert.Ehreke [View]

    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.
  • Generics and Roundtrips
    2006-01-01 19:18:27  ridder [View]

    Shame on you Sean, for being such a jerk! It must be hard to be as smart as you. How do you put up with simpletons like the rest of us? It's too bad you can't find a nice way to educate the rest of us. Perhaps you can write a O/R mapper and an article and then we tell you about all your mistakes!

    As far as I'm concerned, this once again shows the lameness of generics in Java.