Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: How to extend an array Date: Tue, 31 May 2016 11:52:45 -0400 Organization: A noiseless patient Spider Lines: 45 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 31 May 2016 15:52:47 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="2d081e2f7155c28005d4472f67c2f43d"; logging-data="11295"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/P3RyD6hZXLAz8XgyQGCEj" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 In-Reply-To: Cancel-Lock: sha1:Gxp3fSggZsvX5eOVw7sTuOhQ4mw= Xref: csiph.com comp.lang.java.programmer:34424 On 5/31/2016 10:52 AM, Eric Douglas wrote: > This looks funny but seems to work. Does it make sense, is there better syntax, or anything I'm missing? > I have a custom GUI object which needs to generate custom events, and a more complex version of that object which needs to generate those events plus additional events. Here's a simplified sample. > [... code snipped; see up-thread ...] I don't see why Class2 needs its own list of listeners, nor its addExtendedListener() method. Since Listener2 extends Listener1, a Listener2 "is a" Listener1 and can be handled just fine by Class1's addListener() method. Unless there's some additional concern that you've simplified away, I think you're working too hard. Side-issue: Since Class1 and Class2 extend JFrame, they are both Swing components. Swing components are not thread-safe (by and large), so it's not safe to manipulate them from more than one thread. That thread should be the Event Dispatch Thread or EDT. Your code, though, does a *lot* of manipulation of these Swing components on a non-EDT thread: It constructs them, resizes their windows, and makes them visible, all from the startup thread that calls main(). Don't Do That. (To be fair to you, Sun themselves didn't at first realize this was a no-no, and some of the early Swing examples commit this same error. Pay attention to more up-to-date examples, that's all I can suggest.) One simple way to ensure that construction happens on the EDT: public static void main(String[] args) { SwingUtilities.invokeLater(new Runnable() { Class2 myWindow = new Class2(); ... et cetera ... myWindow.setVisible(true); }); (The fashion nowadays is to use a "lambda expression" instead of an explicit "new Runnable()", but I didn't want to risk spooking you.) For "belt and suspenders" safety, I also like to sprinkle assert SwingUtilities.isEventDispatchThread(); in the constructors of my Swingthings, and in some of their public methods as well -- Better to get crashes during development and test than to get baffling unreproducible failures at deployment ... -- esosman@comcast-dot-net.invalid "Don't be afraid of work. Make work afraid of you." -- TLM