Hmm ... the fact that EHCache uses serialization internally does not really bother me. Here's why: a couple of weeks ago, when trying to complete a possible patch for CASTOR-1102, I came to realize that Coherence requires all objects stored in its cache classes to implement java.io.Serializable. Whilst initially I didn't like this idea at all, I came to realize quite quickly that it was really easy to refactor Castor in such a way that both the OID and the newly introduced CacheEntry classes implement Serializable.
With regards to the casting taking place, I came to realize that we don't store the actual object instances in the cache. What is actually stored is an array of field values, most of which all time are of 'primitive' types and thus Serializable by default. Werner Bruce Snyder wrote: > On 8/5/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > >>I noticed comments from another JDO user regarding the lack of an "ehcache" >>implmentation, which I think is the default used by JBoss. The reflection >>API you have placed in the base cache class should make integration of other >>cache API fairly simple. > > > FWIW, EHCache is used in Hibernate by default. I believe that JBoss > uses the JBoss Cache (http://www.jboss.org/products/jbosscache). > > Actually, as I started writing the reflection based stuff with Werner, > I realized that integrating EHCache via reflection is a Very Bad Idea. > This is due to the fact that EHCache utilizes java.io.Serializable > instead of java.lang.Object. More to the point, writing a wrapper that > simply assumes serializability, or worse, casts all objects in a > entire object graph to java.io.Serializable is a Very Bad Idea. > Because of this, the onus would need to be placed on the user to make > sure all of the objects being cached are serializable. > > Bruce ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
