Have you looked at the Spring 3 release and SPeL? You can solve similar problems with that. It overlaps, and covers different areas. In fact if you look at what you can do with SPeL, Hamcrest and Guava the combined extra power is fantastic.

With SPeL you miss out on this ability to form an iterable backed by the original collection, but in some cases it can still be of use. I think your example from above would look a bit like this. Excuse any mistakes I am free coding this!

Iterable filtered = filter(names, or(or(equalTo(“Aleksander”),equalTo(“Jaran”)), lengthLessThan(5)));

List filtered = (List) parser.parseExpression(“#names.?[(Name == 'Aleksander' || Name == 'Jaran') && Name < 5 ]").getValue(names);

Not as pretty by any means, but interesting all the same.

See for detail:
http://static.springsource.org/spring/docs/3.0.0.M3/spring-framework-reference/html/ch07s02.html

Your original code has both an unchecked cast and an unchecked conversion. Seeing as neither are being checked you can write less code and get exactly the same bytecode by only coding the required cast i.e.:

Map<String, Map<String, Collection>> myUglyMap = (Map)webappSession.getAttribute(“myUglyMap”);

Which is the same length as your workaround without having to create an extra utility class and import it.

Now if you wanted to really address the problem you’d need to define the parameterised type Map in a custom class, then perform a checked cast on the object from the session map.

Failing that you could iterate over the contents of the map (and nested map, and collection) checking their types. Without this you are doing an unchecked conversion and should rightly by warned by the compiler- if the cast passes you may still get class casts down the line as other code accesses the data in the Map.