This is the mail archive of the
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: <firstname.lastname@example.org>
- Reply-to: tromey at redhat dot com
>>>>> "Tom" == Thomas Fitzsimmons <email@example.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
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
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.