Hi Thomas, I just can't find the time to have a deep look at JCS - sorry about that. JCS 1.3 targeted Java 1.3 and it was released in 2007. Trunk already contains 2.0-SNAPSHOT so it looks like someone intended to roll out a new major release.
Your explainations sound like we're currently hacking around the Java type system and your proposed solution sounds reasonable (as far as I can judge). So I'd say: go for it. It may be easier to discuss design changes for others when they actually see the changes in the code. Benedikt 2013/10/10 Benedikt Ritter <brit...@apache.org> > Sorry Thomas!!! I intended to have a look at this but then we started a > lot of discussions here. I just forgot it. I'll try to have a look! > > Benedikt > > > 2013/10/10 Thomas Vandahl <t...@apache.org> > >> On 03.10.13 13:30, Thomas Vandahl wrote: >> > Hi folks, >> > >> > I'd like to ask for suggestions for a problem solution regarding the >> > typesafe handling of cache keys in JCS. >> > >> > Previously, JCS was not aware of key and value types. So it was possible >> > to mix cache elements having different key types within the same cache >> > instance. This "feature" was abused to implement the cache groups, so >> > that keys of e.g. type String were combined with keys of type >> GroupAttrName. >> > >> > The current implementation implements this functionality by hacking >> > around the generics type definitions (in all cache implementations) >> > which is definitely not desirable. It also may cause >> ClassCastExceptions. >> > >> > As I see it, it would be better to use some kind of decorator pattern >> > for the GroupCacheAccess functions that wraps around a regular >> > CacheAccess object. This would mean type-safety at the cost of major API >> > changes. Also it would have the advantage that the cache implementations >> > do not have to know about cache groups at all. >> > >> > Are there better solutions? Other ideas how to resolve this? >> > Your thoughts are very much appreciated. >> >> No ideas? Really? Please help, I need a second opinion. >> >> Bye, Thomas. >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > http://people.apache.org/~britter/ > http://www.systemoutprintln.de/ > http://twitter.com/BenediktRitter > http://github.com/britter > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
