Again, this class is not a safe drop-in replacement for Lists in general. Note that some List behavior you simply will not be able to imitate without storing the elements as a List, and some behavior you will only partially be able to imitate. You'd create a class that implements the List interface, takes a Set in the constructor and assigns that Set to a field, and then uses that internal Set to implement the List API (to the extent possible, and desired). Note that this is inherently unsafe (because the library function's requirements from each List could presumably change without you knowing), so another solution should be preferred. In this super niche case, depending on the (maybe unknowable) behavior the library function needs out of your Lists, you may be able to create a List view over each Set. And for some reason you need to avoid the speed/memory overhead of copying each Set to a List. Say that you really do want to treat the Map values as Lists, but you want to avoid copying the Set into a List each time.įor instance, maybe you are calling one library function that creates a Set, but you are passing your Map> result to a (poorly-designed but out of your hands) library function that only takes Map>, even though somehow you know that the operations it does with the Lists are equally applicable to any Collection (and thus any Set).

Set to do list