Hi Paulo,
So it is a won't fix then?
Who say that? There is a bug. It has not the highest priority and it's
the reason why it still not fixed.
Regards, Pavel.
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] <mailto:[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]
<mailto:[email protected]>>
Date: Fri, Nov 13, 2009 at 9:53 AM
Subject: Re: Bug in ShellFolder.
To: Paulo Levi <[email protected] <mailto:[email protected]>>
Cc: [email protected]
<mailto:[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
<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.
