So it is a won't fix then? Seems really short-sighted, since probably forever people will want to serialize things when shutting down the application. Anyway the only operation i found that uses the COM thread is the shellfolder2 class. I'm sure at least this very common case can be worked around i its serialization routine.
On Thu, Nov 19, 2009 at 11:23 AM, Pavel Porvatov <[email protected]>wrote: > 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. >> >> > >
