Well, Eclipse comes with some automated refactorings for moving pre-5 code to generics, but besides that, no.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I was asking because my application seems to be evolving a few parallel components at each level -- two of the fundamental data model items are Lists of X and Lists of Y, which are implemented as rather thin wrapper classes around ArrayList<foo> as appropriate, in the Model Layer. Each has a corresponding ListViewer in the View Layer that's rather isomorphic. Bridging the two is an Editor in the Control Layer that is more unique, but still has some shared functionality.
In some ways it related to the AbstractFactory pattern -- a parameterized family of types that should be used together.
It would be nice to refactor the commonality out of the classes; it looks like the generic that would emerge wuld need to be abstract. While none of the references I've seen on generics talk about what happens when the generic is abstract; the Collection Framework obviously uses it. One difference is that the concrete implementing class would also be binding the type variable at the same time, but I don't see anything that indicates that would be a problem.
However, the complexity of the refactoring and the resulting increasing in complexity of the inheritence/code organization feels a little "unusual". Not a lot of developers (myself included) have a lot of experience with generics (aside friom the Collections) and, thus, the refactoring could make the underlying code harder to work with, not easier....
Does anyone have any experience with using generics to solve issues similar to those solved by abstract factory?