Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!fx11.iad.POSTED!not-for-mail From: Daniel Pitts User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: @java.lang.DontOverride References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Lines: 41 Message-ID: <1K5cv.7545$s87.2913@fx11.iad> X-Complaints-To: abuse@newsrazor.net NNTP-Posting-Date: Mon, 12 May 2014 15:25:49 UTC Date: Mon, 12 May 2014 08:25:58 -0700 X-Received-Bytes: 2641 X-Received-Body-CRC: 3185411266 Xref: csiph.com comp.lang.java.programmer:28447 On 5/10/14 6:40 PM, markspace wrote: > On 5/10/2014 6:16 PM, Stefan Ram wrote: >> class Example extends javax.swing.JComponent >> { public boolean isValid(){ return true; }} >> >> I do not want to override any method of JComponent with my method. >> I just want to add a new method. But now or in future versions of >> Swing there might be an »isValid« method in JComponent. > [snip] > Moreover, I find your request questionable. How do you know what > methods should never ever be overridden in future classes? How do you > know someone won't make a new interface for JComponent, some > ImprovedJComponent, where the "isValid()" method needs to be overridden > by the new classes? It's too hard to predict the future like this. Just > require that your coders learn to read, and especially test, their code > and problems like this become manageable. I think his point is that if "isValid" becomes a member of JComponent, he wants a compiler error so that he knows his implementation may now have different semantics than intended. This is to say "My code is now broken because of an interface change in JComponent." That is a reasonable thing to want to know. > > The keyword "final" is there for the correct behavior of the current > class; that's something you can reasonable predict. Leave the correct > behavior of future classes to future coders. This is for defining a class that is to be extended, not for defining the extending class. Stefan, I think the real answer is "Don't add non-private methods to your JComponent extension." Instead, create a different class that provides a JComponent object (perhaps a getComponent() method). All of the "business" logic that affects the component will live in your non-component class, or in the appropriate standard methods of your component class. HTH, Daniel.