This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
If the implementation of a clone() method does in fact invoke super.clone(), but super.clone() has a return type other than java.lang.Object, the "clone() does not call super.clone()" hint is erroneously displayed. Example code: public class A implements Cloneable { @Override public A clone() { try { return (A) super.clone(); } catch (CloneNotSupportedException e) { throw new RuntimeException(e); } } } public class B extends A { @Override public B clone() { // "clone() does not call super.clone()" erroneously displayed on this line return (B) super.clone(); } } A non-Object return type for clone() is allowed both by the rules of Java and the contract of clone(), and can be convenient (it can save casts in many places) so I think the hint should take it into account.
Works for me fine in the current dev build.
Created attachment 145348 [details] A screenshot showing the problem in the latest nightly build (201402180001) As you can see from the screenshot I attached, the problem is still present in the latest nightly build (201402180001).
By the way, as you can also tell from the screenshot, the tooltip for the hint is also wrong. It says "clone() calls super.clone()", which should be "clone() does not call super.clone()" (even though of course in this case that is false). The hint should describe what is wrong (like the other hints do), not how it should be.
I was kind of lazy and attempted to reproduce the defect on two nonpublic classes inside the same source. The hint does not appear in that situation - weird. Reproduced on 2 toplevel public classes.
In fact, the defect traces led to java.source module - getOverridenMethod() returned a synthetic bridge although a real method was available. So in your case, getOverridenMethod() returned Object clone() bridge present in A class, which was != from super.clone() (that resolved to A clone() method) and produced the suggestion. Fixed in jet-main#e649a4e3f874 The reproduction is +- probabilistic ;) as it depends on ordering in class members hashtable buckets :)
Integrated into 'main-silver', will be available in build *201402200001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/e649a4e3f874 User: Svata Dedic <sdedic@netbeans.org> Log: #241755: favor real methods over synthetic bridges
I can confirm that the problem is indeed fixed in nightly build 201402200001. Thanks!