Out of curiosity, how significantly different do you feel your additional
class is from simply changing the constructor for each of Batik's HashMaps
(or any other implementation of the java.util.Map interface) with
Map m = Collections.synchronizedMap(new HashMap());
Do you feel that yours
My HashMap is not synchronized, its threadsafe. i.e. if you have two
threads modifying it at once, it will never throw exception, be
corrupted, or block.
A synchronized class will block, and sometimes a thread contention can
cause part of a program to block forever.
On Tue, 2003-06-17 at 21:53,
To the guys here, of course, and maybe to the guys on Jakarta Commons
(Sub-subproject Collections,
http://jakarta.apache.org/commons/collections.html). They already have a
bunch of alternative implementations. Maybe they already have something
like you did, but then, maybe not. At least, I think
Hi Brian,
Brian Modra wrote:
Batik crashes when updating due to concurrent modification exceptions
in Sun's HashMap class. Rather than describe this in detail (it happens
in a number of different sequences of events) I think its enough to say
that the exceptions are thrown as a result of AWT
Hi Thomas,
thanks for your reply.
My replies are in-line below...
Brian
On Mon, 2003-06-16 at 20:58, Thomas DeWeese wrote:
Hi Brian,
Brian Modra wrote:
Batik crashes when updating due to concurrent modification exceptions
in Sun's HashMap class. Rather than describe this in detail (it
In my email a few minutes ago, I mentioned that the
scheduleGVTRendering() can get called rapidly and wildly if someone is
dragging the corner of a window... I solved this problem by the
following addition to JGVTComponent constructor:
addComponentListener(new ComponentAdapter() {
public void
