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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > 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: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
