Bug ID: JDK-4145996 spec for ctor java.util.EventObject unclear

Type: Bug
Component: core-libs
Sub-Component: java.util
Affected Version: 1.0_d,1.2.0,5.0

Priority: P4
Status: Closed
Resolution: Fixed
OS: generic,solaris_2.5
CPU: generic,sparc

Submitted: 1998-06-05
Updated: 2017-05-16
Resolved: 2004-09-15

Other
5.0 tigerFixed

Name: sdC67446			Date: 06/05/98


The spec for ctor java.util.EventObject(Object source)
does not specify behavior if 'source' == null.
Currently ctor throws uexpected IllegalArgumentException.

--------------Here is what doc says:--------------
public EventObject(Object source)

      Constructs a prototypical Event
      Parameters:
            source - The object that the Event occurred upon.

-----Here is the test demonstrating the bug:------
import java.util.EventObject;
public class Test  {
    public static void main(String[] args) {
        try {
            EventObject eo = new EventObject(null);

        } catch (Exception e) {
            System.out.println(e);
        }
    }
}
-----Here is output from test:--------------------
java.lang.IllegalArgumentException: null source
--------------------------------------------------
======================================================================

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b07 VERIFIED IN: 1.5

17-09-2004

EVALUATION From ###@###.###: I agree wholeheartedly that the current behavior is wildly unexpected given the spec. Further, the exception thrown contradicts convention: it should be NullPointerException rather than IllegalArgumentException. We have three reasonable choices: 1) Document the current behavior with an @throws comment. 2) Change the exception to NullPointerException and document that. 3) Eliminate the exception and document that a null source is permitted. Technically speaking, all three of these may be classed as "refinements" as none contradicts the current spec. The first is the least disruptive, as it involves no change in behavior, but is unsatisfying because the wrong exception type is thrown. As to which of (2) and (3) are preferable, I think you should ask someone who is more familiar with the Beans architecture (e.g., Eduardo Pelegri-Llopart or Graham Hamilton). For many "wrapper objects", it is good to throw an exception as soon as you wrap something bogus, rather than throwing the exception long after the damage has been done. On the other hand, there may well be valid reasons to wrap a null source object. From ###@###.###: Tricky. My instinct is that it should be OK for the source to be null. Given the way beans events work sometimes there isn't a well defined source. So I tend to lean towards allowing the source to be null. The main risk is if people are doing things like: if (evt.getSource().equals(foo)) then the change may cause problems. But I don't think people actually do this in practice. At least not unless they are very sure of the definition of the source object for a given event, in which case it won't be null. Of the three options, I really dislike (1) the status quo. It's clear we're throwing the wrong exception. I could live with (2). It would tend to prefer (3). From ###@###.###: I strongly prefer (3). Technically, (2) vs. (3) is a bit of a wash (though 3 seems better). The real reason why I prefer 3 is that this represents no spec change: The spec does not prohibit a null argument. I contend that the current behavior contradicts the spec, and is simply a bug. If spec writers were required to explicity state every place that a null argument *doesn't* cause an exception to be thrown, just imagine the spec carnage! That's why I claim that the present spec allows a null argument. Making our implementation conform to our spec is IMHO the only solution that truly preserves interoperability -- cleanroom implementations do exist, and are allowed by our licensing structure. Changing the spec (option 1) would break programs that relied on the specified behavior. From ###@###.###: I think that we all prefer (3), so that's what we'll do. Alan, you should feel free to move this to the classes_util category and re-assign it. The above changes were proposed but it has been decided that compatibility is more important for this legacy class, so the current behavior has been clarified in the spec. ###@###.### 2003-04-21

21-04-2003

Duplicate :	JDK-4935655 - EventObject's constructor throws IllegalArgumentException
Relates :	JDK-4885993 - java.awt.datatransfer.FlavorEvent: null reaction