Hi Paulo,
The problem is described in the bug 6612928:
Since 6u2 b01 we use the concurrent package to marshall COM calls to the
dedicated thread. The investigation shows that this exception is thrown
with a scenario like this:
1) user exits the application
2) the JVM starts invoking shutdown hooks
3) the COM thread's shutdown hook initiates shutdown of
ThreadPoolExecutor (used for marshalling COM calls to the dedicated thread)
4) a new COM call is submitted from within another thread
Couldn't something equivalent be done in writeReplace be used for the
same thing inside one of those classes?
Therefore you shouldn't call any methods that use COM thread after a
shutdownhook. As a temporary workaround you can try to cache values for
serialization BEFORE a shutdownhook is initialized.
Regards, Pavel
Forward. I already resolved it by serializing the string instead of
the file, but i thought you should know, if you don't already, why
people are seeing this exception on shutdown.
---------- Forwarded message ----------
From: Alan Bateman <[email protected]>
Date: Fri, Nov 13, 2009 at 9:53 AM
Subject: Re: Bug in ShellFolder.
To: Paulo Levi <[email protected]>
Cc: [email protected]
Paulo Levi wrote:
In this thread, i found a bug similar to a strange exception i was
(not) seeing when overriding writeObject
http://forums.java.net/jive/thread.jspa?threadID=31316&tstart=0
I found that it occurs because of saving files returned by the
filechooser (extensions of sun.awt.shell.ShellFolder) when trying to
serialize on a shutdownhook,
because serializing triggers some file operation that needs to send a
task to a Executor that is already closed.
I avoid it by:
out.writeObject(new File(((File) first).getAbsolutePath()));
Couldn't something equivalent be done in writeReplace be used for the
same thing inside one of those classes?
Sorry, I can't help you here - I would suggest bringing it up on one
of the Swing forums or mailing lists.
-Alan.
