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.
Product Version: NetBeans IDE 6.0 (Build 200711261600) Java: 1.6.0_03-ea; Java HotSpot(TM) Client VM 1.6.0_03-ea-b01 System: Linux version 2.6.5-1.358 running on i386; UTF-8; en_US (nb) Generating getter & setter should respect names of inner static class and not to try add import and use plain name. See the following testcase: 1) have a class: import java.awt.geom.Point2D; public class NewClass2 { Point2D.Double d; } 2) generate getter / setter for filed 'd' -> result: import java.awt.geom.Point2D; import java.awt.geom.Point2D.Double; public class Test { Point2D.Double d; public Double getD() { return d; } public void setD(Double d) { this.d = d; } } the result is correct but better would be to generate following code w/o adding import: public Point2D.Double getD() { return d; } public void setD(Point2D.Double d) { this.d = d; } Note this can also break source if the original class Test already contains filed Double x - see issue 123053
The import problem should be gone.
Someone in my office just encountered the same problem today. He had generated a getter/setter for a field of type Rectangle2D.Double and was very confused when the getter's declared type was Double. He thought that it was referring to java.lang.Double; another developer casually browsing the generated code would likely come to the same conclusion. While it is technically correct with respect to the compiler, I agree with jiriprox that this is bad style. I would have written the getter to return Rectangle2D.Double and the setter to take a Rectangle2D.Double parameter, so I would expect code generation to create the same thing. BTW, I was able to reproduce this on NB 6.5M1. Details of my configuration follow: Product Version: NetBeans IDE Dev (Build 200807040101) Java: 1.6.0_07; Java HotSpot(TM) Client VM 10.0-b23 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Userdir: C:\Documents and Settings\tq232c\.netbeans\6.5m1
Resolving all issues with milestone "future" as LATER. If you feel strongly that it should be implemented please reopen and set the target milestone to "next".
NetBeans.org Migration: changing resolution from LATER to WONTFIX
I am reopening this because I can still reproduce this, even in a recent nightly build. Here are the steps I can use to reproduce this problem, using NetBeans IDE Dev (Java SE Build 201110160600) on Windows XP using Java 1.6.0_25. However, I want to be clear that this is mainly a matter of usability and confusion -- the code generated is technically correct, just misleading. For more information, see what I wrote in issue #203867 (Hint implies incorrect type in Quick Fix assignment).
I see this behaviour with NB 7.2. A (probably) related behaviour is seen when implementing an interface where a method returns an inner class. Example: public interface Foo { Point2D.Double getPoint(); } Asking NB to generate an implementing class, or starting to create one by hand and then asking NB to generate a method body, produces: import java.awt.geom.Point2D.Double; public class FooImpl implements Foo { @Override public Double getPoint() { throw new UnsupportedOperationException("Not supported yet."); } } This occurs despite the preference Formatting->Java->Imports->Use single class imports->Import inner classes being false.
Fixed in jet-main. http://hg.netbeans.org/jet-main/rev/815fbc14a2e5
Integrated into 'main-golden', will be available in build *201212140001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/815fbc14a2e5 User: Dusan Balek <dbalek@netbeans.org> Log: Issue #123054: Better handling inner classes when generating getters & setters - fixed.