how to wrap a pre-generics library

I have a pre-generics library that stores different object types in Maps and Lists. The interfaces to this library are in terms of raw Maps and Lists. Is there a good way to wrap or encapsulate the classes of this library so that I can get rid of the zillions of "raw type" warnings I'm getting?

As it happens, the Maps are all keyed on String, and the contents of these Maps and Lists all fall into a fairly limited set of types (String, Map and List).

The best idea I've come up with is to use delegation - write (for each legacy class) a class that contains an instance of the legacy class and provides properly typed access methods. One problem with that is that the delegation would not be straightforward - the delegating methods would have to unpack the typed stuff and repack it in untyped variables on the way out to the legacy classes. They'd have to package the untyped stuff in typed variables on the way in from the legacy objects. I would really prefer not to have to set up a superclass and subclass containers for non-generic String, Map and List types...

Hope this all makes sense to someone :-)

FB.

I'm a bit unclear as to why you want to do this...is it just to get rid of the warnings, or do you want more defined compile time type checks? For the former, you can use the @SuppressWarnings annotation. For the latter, I am not aware of a way to go about it other than wrapping it through delegation, or rewriting the library.

I would just add the generics, if you feel it is necessary. If the Maps and Lists are all internal and still work fine, just do @SuppressWarnings and forget about it. If they are public and part of the documentation, I would change them, as it will be confusing/annoying for programmers to work with your non-generics based Map/List as opposed to what they are used to.

EDIT:
You could, perhaps, wrap the classes by renaming the old ones (and remove public modifier so that they are 100% internal) and then just create some new rather short generics supported classes with the previous names. The new classes could just do some simple interfacing with the old ones through type-casting and such. I think Sun might've done that with JList in JDK7... but don't quote me on that :D