jsf 2 - Arguments against a generic JSF object converter with a static WeakHashMap -

i want avoid boiler plate code creating list of selectitems map entities/dtos between view , model, used snippet of generic object converter:

@facesconverter(value = "objectconverter") public class objectconverter implements converter {  private static map<object, string> entities = new weakhashmap<object, string>();  @override public string getasstring(facescontext context, uicomponent component, object entity) {     synchronized (entities) {         if (!entities.containskey(entity)) {             string uuid = uuid.randomuuid().tostring();             entities.put(entity, uuid);             return uuid;         } else {             return entities.get(entity);         }     } }  @override public object getasobject(facescontext context, uicomponent component, string uuid) {     (entry<object, string> entry : entities.entryset()) {         if (entry.getvalue().equals(uuid)) {             return entry.getkey();         }     }     return null; }  } 

there many answers similliar questions, want vanilla solution (without *faces). following points still leave me uncertain quality of snippet:

1. if easy, why isn't there generic object converter build jsf?
2. why many people still using selectitems? isn't there more flexibility using generic approach? e.g. #{dto.label} can changed #{dto.otherlabel}.
3. given scope map between view , model, there major downside of generic approach?

this approach hacky , memory inefficient.

it's "okay" in small application, not in large application tens or hundreds of thousands of potential entities around referenced in f:selectitems. moreover, such large application has second level entity cache. weakhashmap becomes useless , effective when entity physically removed underlying datastore (and second level entity cache).

it has "fun" factor, i'd not recommend using in "heavy production".

if don't want use existing solution utility library omnifaces selectitemsconverter found, stateless , doesn't use dao/service call, best bet abstract entities common base interface/class , hook converter on instead. still requires dao/service call. has been fleshed out in detail in q&a: implement converters entities java generics.