Globally agree Next question is: do we plan a 2.0.0-alpha without it (said otherwise I'd like JCache to be out ASAP and avoid what we live @BVal taking soon 1 year to release) or do we wait to be very stable to do a proper 2.0.0?
Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-26 21:45 GMT+02:00 Bernd Eckenfels <e...@zusammenkunft.net>: > Hello, > > I think it is usefull to have an Interface which allows > non-serializeable Keys and Values. First of all this is usefull for > actual in-heap implementations (and a generic Map<?,?> replacement) but > also for a modular approach where you can plug-in custom serializers. > > In fact I would consider this the majority of usecases, as Java > Serialisation is really a pain... > > Anyway, I could understand that one wants some stricter Enforcement of > posible keys/values (therefore avoiding runtime exceptions). Personally > I dont see much win in it, after all after doing it wrong once you > would likely use proper generic declaration anyway. > > I think CacheAcces should be <K extends Object, V extends Object> and > the JCS.xxx methods can declare different return types. So we can keep > all the old define/get with <K extends Serializeable, V extends > Serializeable> but have new getters which limit, like > > CacheAccess<K,V> getInstanceWithSerializers(String name, > Serializer<K,V> serializer). > > And Serializerer beeing something like: > > Serializer<K,V> { > byte[] getKeybytes(K key); > byte[] getValueBytes(V val); > K constuctKey(byte[]) > V constructValue(byte[]) > } > > (We could even implement as "JavaSerializer implements > Serialier<Serializable,Serializable>")? > > > Gruss > Bernd > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
