jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Travis Savo <ts...@IFILM.com>
Subject RE: xml config prototype
Date Mon, 19 Apr 2004 18:44:35 GMT
At what point does it become acceptable to move on to a new rev, and embrace
the features of it?

I ask because the idea of a region genericized on a type ala JDK 1.5 seems
very very attractive to me.

In my mock code here, the region name defaults to the fully qualified class
name of the class it's generic'ed around (<T>.class.getName()), but it could
optionally be specified manually at construction via a string (aka the old
way):

import com.commercial.specific.*;

...

  JCS<com.commercial.specific.TypedObject> jcs = new
JCSAccess<com.commercial.specific.TypedObject>();
  TypedObject someTypedObject = new TypedObject();
  jcs.put(1, someTypedObject);
  TypedObject someCachedTypedObject = jcs.get(1); // Note the lack of cast!

...

Just genericing on the cached object type eliminates the cast when doing a
get. You could take it a step further and genericize on the key as well, but
I'm not entirely convinced it's necessary. It may be useful to say "This
region only uses keys that are Strings (or Integers, or composite objects of
a specific interface, or whatever)".

...

  JCS<java.lang.String, com.commercial.specific.TypedObject> jcs = new
JCSAccess<java.lang.String, com.commercial.specific.TypedObject>();
  TypedObject someTypedObject = new TypedObject();
  jcs.put("hooba", someTypedObject);
  TypedObject someCachedTypedObject = jcs.get(1); // This would throw a
compile-time error, because '1' is not a String.

...

Also, autoboxing allows for that '1' there in the get and put, instead of
'new Integer(1)', yet retains backwards compatibility with code doing the
'new Integer(1)'. And you get that for free when upgrading.

Not to mention RMI stubs are auto generated (at run time I believe?),
eliminating that extra step with remote cache.

Clearly this is in the future as 1.5 isn't even out of beta, but my question
remains because this does seem so compelling to me.

Would we need to do a fork? Could we then embrace the cool toys that require
1.4 as well? Would such a fork be officially supported?

-Travis Savo


-----Original Message-----
From: Aaron Smuts [mailto:aasmuts@wisc.edu]
Sent: Monday, April 19, 2004 8:27 AM
To: 'Turbine JCS Users List'
Subject: RE: xml config prototype


Xstream says it requires 1.4.

This is getting to be a problem.

Aaron

> -----Original Message-----
> From: James Taylor [mailto:james@jamestaylor.org]
> Sent: Monday, April 19, 2004 6:00 AM
> To: Turbine JCS Users List
> Subject: Re: xml config prototype
> 
> > The problem is mainly with the auxiliaries.  A new auxiliary can
have
> > all sorts of parameters unique to itself.  A memory plugin could
have
> > some configuration parameters that are also unique.
> 
> Might want to look at xstream (xstream.codehaus.org), I think it
> handles this case better than digester (and it seems much simpler to
> use).
> 
> -- jt
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
turbine-jcs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-jcs-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org


Mime
View raw message