jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <aasm...@wisc.edu>
Subject RE: xml config prototype
Date Mon, 19 Apr 2004 23:57:14 GMT
Perhaps something like this could go in experimental folder or we could
have a subfolder of the experimental for a new jdk.  

Aaron

> -----Original Message-----
> From: Travis Savo [mailto:tsavo@IFILM.com]
> Sent: Monday, April 19, 2004 1:45 PM
> To: 'Turbine JCS Users List'
> Subject: RE: xml config prototype
> 
> 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


---------------------------------------------------------------------
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