Hi Bogdan,
Bogdan <[EMAIL PROTECTED]> wrote on 07/08/2008 12:27:17 PM:
> I'm using batik (JSVGCanvas to be precise) in one of my programs and
> I've noticed a strange behaviour: batik reports a null pointer. I
> can't give exact steps to reproduce the problem, but the algorithm is
> simple: be sure the canvas is active and displaying some elements
> (works best when adding them on a different thread) and push many,
> many events changing the root element's "viewbox" attribute. SVGCanvas
> slows down and often stops reporting a null pointer.
Helder responded to this question on the user's list and asked
if you were making sure to follow the thread conventions for manipulating
the DOM from Java:
http://xmlgraphics.apache.org/batik/using/scripting/java.html#Threads
Not ensuring that all manipulations of the DOM take place in the
UpdateManager's RunnableQueue is a sure way to get bugs like this
(and much worse). Since you didn't respond to Helder I don't know
if you checked for this or not.
> Using a debugger I was able to find out that "gn" can be null and
> this is what's causing the problem. Please include a check for null in
> "gn". If I'm doing something wrong that may be causing this, tell me
> so and include a check for null in "gn".
It's hard for me to come up with a scenario where gn would be
null there unless someone had already caused a rebuild of the document
that was still active in another thread (i.e. you are manipulating the
DOM outside of the UpdateManager's thread). So I'm leaning towards
this being caused by a bug in your code.
I am not fond of adding checks like you propose that only act to
mask the true problem (be that in your code or somewhere else in Batik).
So unless it can be demonstrated that there is a legitimate reason
for gn to be null in some cases I'd rather have it cause the exception
than lead to 'silent' bad behavior (like in some case not ever showing
the document or showing a 'wrong version' of the document).
> If this error is caused by some other module, notify its author
> and ...
Consider this done :)
> include a check for null in "gn" anyway.
Respectfully declined, at least for the moment.
One of the nice things about open source is that you are free to
take the source and make such a modification "so you can get product out"
if you feel that is required.
> synchronized (result) { // get the object's monitor for "result.wait"
>
> Apart from acquiring the monitor, synchronization on a local object
> indeed has no meaning as for me.
It's not really a local object since that object is the
Runnable of a new Thread. So the synchronize let's us block
return until the new thread is fully initialized and ready to
be used (meaning that the RunnableQueue object is fully initialized
and ready to be used):
synchronized (result) {
// Sync on the new object, so we can wait until the new
// thread is ready to go.
