Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: "James Carman" <james@carmanconsulting.com>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Subject: RE: TimerMap
Date: Mon, 24 Nov 2003 15:42:09 -0500
Organization: Carman Consulting, Inc.
Message-ID: <003101c3b2cb$6efc0060$7c44058f@NAMRAC2247>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <59A58FAA-1EBE-11D8-8F4D-000393A577F4@25thstreet.net>
Importance: Normal

Maybe you could just go ahead and throw UnsupportedOperationException on
keySet(), but implement a generic debugCachingIssues() method!  ;-)


-----Original Message-----
From: Joseph Rosenblum [mailto:joey@25thstreet.net] 
Sent: Monday, November 24, 2003 3:40 PM
To: Jakarta Commons Developers List
Subject: Re: TimerMap


Hey there,

Thanks for all the feedback! Ideally, I think this makes the most sense 
as a Map --since it's most common use cases are as a Map-- and the 
javadoc would spell out usage scenarios and challenges (something I 
will work on).

I've changed two points: TimedMapKey is now private and the backing 
store is no longer synchronized (as per Arun's suggestions). 
Synchronization can be left to the client developer.

Even though I wouldn't want to have client code accessing entries via 
iterator in normal usage, I don't think calling keySet() should throw 
an UnsupportedOperationException since examining the keySet of such a 
map could be very useful in debugging caching issues.

Thanks,

-Joe

Joseph Rosenblum | 25th Street Networks
Easy, Reliable Web Hosting @ http://www.25thstreet.net/


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org