Hi. I sent an email about this to the list this morning a few seconds before I actually confirmed my subscribe request, so maybe it did not distribute this email... So here it is again:
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 thread doing a resize, at the same time as batik's queue is processing something queued by invokeLater. Both threads cause an SVG document update, which sometimes causes the concurrent modification exception in the hash map. I've come across this type of problem before in other applications: its due to Sun's HashMap not being thread safe. I looked at the problem and decided that it would not take much effort to write a new HashMap class which was just as fast, and also thread safe. My new HashMap is fast, and its only synchronised where it absolutely needs to be. It is completely thread safe - no concurrent modification problems, and no blocking thread contentions. I've modifying my copy of Batic sources so that it uses my HashMap rather than any other HashMap or HashTable classes (Suns's or Batik's). With the new HashMap class, the contentions go away, and I think this results in a MUCH more stable SVG renderer. Can I put these changes in to Batik's source code? Who should I talk to? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
