JDK-4715486 : field focusEvent.opposite is not transient
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2002-07-16
  • Updated: 2002-10-04
  • Resolved: 2002-10-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
Description
###@###.### 2002-07-16

FocusEvents in JDK 1.4.1 provides a reference to the "opposite"
component...that is a reference to the component which lost focus when your
component gains focus, and a reference to the component that gained focus
when your component lost focus.

That's great, but FocusEvent is Serializable and field focusEvent.opposite
is not transient.

Therefore, cannot ship FocusEvents over RMI without serializing whatever
component is the opposite component.

java.awt.event.FocusEvent and most other events ultimately derive
from java.util.EventObject, which contains the following:

public class EventObject implements java.io.Serializable {
   /**
    * The object on which the Event initially occurred.
    */
    protected transient Object  source;
    :
    :

Thus, if you serialize an event, the source that you get on deserialization
will be null.

The opposite component in FocusEvent should work the same way, even if only
for consistency.  (Both source and opposite refer to components at the time
the event object was created.)

We believe null is the *only* reasonable value upon deserialization,
especially given that source will be null.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b03
14-06-2004

EVALUATION Commit to fix in mantis (CAP). ###@###.### 2002-07-16 The integration comment for this bug states: > 4715486 focusEvent.opposite should be transient > Actually, we can't make the field transient since it will break > compatibility with 1.4, but we can make it serialize and > deserialize always to null in 1.4.2 (that's what the fix does). > Customer who submitted the bug verified that this will be good > enough for their that had problems due to this bug. I'm confused--if we're always serializing and deserializing the value as null, how is this any different than marking the field transient? If you mark the field transient, then the serialization stream will carry no value for the field, so the deserialized FocusEvent instance will naturally have null as the value for its "opposite" field; similarly, the fact that the field is transient would mean that non-null "opposite" values transmitted as part of FocusEvents sent from earlier JDKs (for which the "opposite" field is non-transient) will be discarded, leaving the "opposite" field set to null in the newly deserialized instance, which is the desired behavior, correct? In short, it seems to me that simply marking the field as transient in 1.4.2 is a simpler solution that has the same effects in the end as the recently-integrated fix, and moreover describes more clearly the intent of the change--namely, that the "opposite" field really should not be part of the serialized form of FocusEvent. ###@###.### 2002-10-04
04-10-2002