This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: Window and Dialog fixes
- From: Tom Tromey <tromey at redhat dot com>
- To: Thomas Fitzsimmons <fitzsim at redhat dot com>
- Cc: GCJ Patches <java-patches at gcc dot gnu dot org>
- Date: 04 Sep 2003 12:02:39 -0600
- Subject: Re: Patch: Window and Dialog fixes
- References: <1062691967.12488.117.camel@tortoise.toronto.redhat.com>
- Reply-to: tromey at redhat dot com
>>>>> "Tom" == Thomas Fitzsimmons <fitzsim@redhat.com> writes:
Tom> Please review and comment.
This is pretty good. I think there are a few problems though.
Tom> * java/awt/Frame.java: Move owned windows logic to ...
Tom> * java/awt/Window.java (ownedWindows, owner, weakThis): New
Tom> fields.
I'm curious about this. In the current Frame code, ownedWindows is
marked with @serial. If this field is specified by serialization,
then we either need to keep it in Frame or add readObject/writeObject
methods.
Likewise, fields added to a serializable class have to be marked
transient if they aren't mentioned in the serialization spec.
There's a "serialized form" link from each page of Sun's javadoc.
I'd prefer a different implementation of the owned windows code. It
would be better if we could get rid of Window.finalize(). Also we
shouldn't need the weakThis field, I think.
I think Window.hide() will fail during the window between when the
`weakThis' is cleared and when the actual window is finalized -- this
isn't an atomic operation. In this situation, I'd expect a
NullPointerException. Also, it seems like the number of owned windows
could change during the loops in dispose(), hide(), getOwnedWindows(),
etc, as there is no synchronization.
+ /* Apparently a jboolean can have a value greater than 1. gboolean
+ variables may only contain the value TRUE or FALSE. */
Hmm, when can this happen? The code looks fine, but I hope the
comment isn't accurate -- a jboolean should only ever be 0 or 1.
Tom