jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hanson Char" <hanson_c...@yahoo.com>
Subject RE: xml config prototype
Date Mon, 19 Apr 2004 21:10:34 GMT
Sadly the currently 1.5beta release does not allow generics to be compiled
to earlier jdk versions.

Hanson

-----Original Message-----
From: Travis Savo [mailto:tsavo@IFILM.com]
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: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:
rbine-jcs-user-help@jakarta.apache.org   -----------------------------------
---------------------------------- To unsubscribe, e-mail:
turbine-jcs-user-unsubscribe@jakarta.apache.org For additional commands,
e-mail:
urbine-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