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

Reply via email to