True. However there is 1.5->1.4 bytecode dehancers, such as RetroWeaver (http://retroweaver.sourceforge.net/) which allow you to compile with 1.5, and deploy on 1.4.
For the sake of my question, it's safe to assume you'll be targeting 1.5. -Travis Savo (P.S. I'm still preparing my reply for questions posted earlier today, and my patch environment. Stay tuned to this channel for more) -----Original Message----- From: Hanson Char [mailto:[EMAIL PROTECTED] Sent: Monday, April 19, 2004 2:11 PM To: 'Turbine JCS Users List' Subject: RE: xml config prototype Sadly the currently 1.5beta release does not allow generics to be compiled to earlier jdk versions. Hanson -----Original Message----- From: Travis Savo [mailto:[EMAIL PROTECTED] Sent: Tuesday, 20 April 2004 4:45 AM 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
