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 a resource is loaded from a classpath, say: welcomeLabel.setIcon(new javax.swing.ImageIcon(getClass().getResource("/SunSPOT/ball.png"))); When the package name is changed due to refactoring , from SunSPOT to FuBar, the resource locations are not changed. This is in Generated code using the GUI builder. Worse, after the failure of refactroing, the Properties editor refuses to enable the 'OK" button to allow you to select a new location for the resource and it has to be entered into the properties field manually.
Is anyone even going to LOOK at this bug?? It is still glaringly present in 5.5.1beta, and causes a HUGE amount of additional manual work (which cannot be automated, as it is in generated code which can't be edited by hand!!!)
Turns out that this defect is more widespread. Rename/refactor on a NetBeans Module project fails almost completely. It will rename the package name, but it fails to find almost ALL occurances of the old package name in the myriad xml files generated, and never changes ANY of those occurances. the rename/refactor is therefore completely useless as the re-named Module will not compile/deploy. Maybe bumping this up to P1 will cause someone to at least *evaluate* it.
Refactoring of forms...
*** This issue has been marked as a duplicate of 48288 ***
Preferably the generated code would in this case look like welcomeLabel.setIcon(new ImageIcon(getClass().getResource("ball.png"))); and thus not be affected by package renames to begin with. I would suggest that be opened as a separate RFE - the property editor for Icon should use relative paths when the image is in the same package (or a subpackage) of the form. The comment in issue #48288 talks about ResourceBundle references, but this bug as stated talked about icons. In the case of ResourceBundle, there is no real issue for module development, since the correct bundle template is field.setText(NbBundle.getMessage(Form.class, "Form.field")); which is unaffected by package renames. (You can and should select this format in the bundle-aware property editor for String properties when doing NB module development. Ideally the form editor would automatically switch to this by default when it detects NbBundle in the classpath.) For non-NB-module project types, however, ResourceBundle.getBundle must be used, which involves a full package name. I would not assume that issue #48288 covers updating these references (perhaps it does?); and anyway the same method might be called from any Java code (not created by the form editor), which ought to be updated after a package rename - this is probably an RFE for refactoring/java, but I'm not sure.