Community
Participate
Working Groups
200406111814 (RC2) I don't know if this is a bug, or if it's just "the way it is", but it doesn't seem very useful as-is... I turned on Warnings for "Empty block not documented" and "Parameter never read", and a whole bunch of them showed up in abstract classes. Technically, it is true that the parameters to every single method in an abstract class are never read, however that information is not very useful to me. I already know that. The same with "Empty block not documented" (i.e. I already know that abstract classes always have an empty block for every method - why are you telling me this?). (The methods are even Javadoc'ed - doesn't that count as "documented"?)
I would expect to have abstract methods in abstract classes. Why are your abstract classes providing methods with no behavior ?
These were discussed quite a long time ago, and consensus was reached around the implemented behavior. Abstract methods are considered special for the unused argument diagnosis (as natives), standard methods are not special, no matter whether they are defined in abstract classes (which means nothing for these methods which aren't abstract). As for comments, the idea is that a block comment must live inside it, not before, not after. Thus void foo() {} // empty isn't considered as commented (for this diagnosis) where void foo() { /* empty */ } is properly commented. Considering leading comment (like javadoc) for documenting these was considered, but rejected in the end, since usually the leading comment would depict the protocol, where specifics are usually part of the body of the method. So an empty body is usually an implementation detail, and should thus be documented inside the code itself. This isn't an absolute law, but rather a heuristic which happens to match most usecases. If we wanted to please everybody, I suspect we'd have to come up with so many suboptions, that it would become unmanageable. Is it ok to close ?
Yep - ok to close. As for why our abstract-class methods aren't declared abstract, I have no idea... I'll have to ask SN what the history is... <g>
Closing
FYI, just to satisfy my curiosity and yours, I looked at our abstract classes that have non-abstract methods, and most of them are similar to the adapter class pasted below. As you can see, we really do intend to have an abstract class with non-abstract empty methods. The javadoc for each method says "The default behavior is to do nothing." So I guess what you are saying is that if we want to turn on "Empty block not documented", then we need to add /* empty */ to our "Adapter" class method bodies so that the compiler does not flag it. Oh well, I guess I just won't turn on that flag <g>. Here's the sample class: package org.eclipse.swt.events; /** * This adapter class provides default implementations for the * methods described by the <code>ControlListener</code> interface. * <p> * Classes that wish to deal with <code>ControlEvent</code>s can * extend this class and override only the methods which they are * interested in. * </p> * * @see ControlListener * @see ControlEvent */ public abstract class ControlAdapter implements ControlListener { /** * Sent when the location (x, y) of a control changes relative * to its parent (or relative to the display, for <code>Shell</code>s). * The default behavior is to do nothing. * * @param e an event containing information about the move */ public void controlMoved(ControlEvent e) { } /** * Sent when the size (width, height) of a control changes. * The default behavior is to do nothing. * * @param e an event containing information about the resize */ public void controlResized(ControlEvent e) { } }
Maybe post 3.0 we could add a suboption to include method/class bodies or not...
post 3.0
JDT/Summit topic
pls see bug 118217 for a better solution to this *** This bug has been marked as a duplicate of bug 118217 ***
Verify for 3.3M7 with I20070503-1400.
