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.

Bug 149442 - 'Move' refactoring does not move/copy keys from resource bundle
Summary: 'Move' refactoring does not move/copy keys from resource bundle
Status: NEW
Alias: None
Product: guibuilder
Classification: Unclassified
Component: Code (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@guibuilder
: 151759 (view as bug list)
Depends on:
Reported: 2008-10-08 04:23 UTC by David Konecny
Modified: 2009-05-25 20:57 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description David Konecny 2008-10-08 04:23:16 UTC
I moved a class to a different package/module and all NbBundle.getMessage(SomeClass.class,"XXX") were correctly updated
to new class but resources stayed in original bundles.

Please reassign if this should be handled by properties or some other module.
Comment 1 Jan Becicka 2008-10-08 09:38:33 UTC
properties module should implement its refactoring plugin.
Comment 2 David Konecny 2008-10-14 23:21:04 UTC
This should be address for 7.0. I just moved a form between two NB modules and result is that all my bundle values like
'org.openide.util.NbBundle.getMessage(AntArtifactChooser.class, "LBL_AACH_ProjectJarFiles_JLabel")' were replaced with
'"null"' which now I have to go and fix by hand. Thanks.
Comment 3 Tomas Pavek 2008-10-15 18:45:38 UTC
I doubt we will be ever able to fix this. Moving/copying entries in properties files based on analyzing java code that
might use it is quite messy. There are many patterns that can be used, the reference to the properties file is often a
String that may need to be changed. If it is a String with full resource name, it remains valid if the class where used
is moved within the same project classpath (no change needed). If the class goes to another project, the properties
files becomes unreachable. Where should the new one be created for the moved class?

Case like NbBundle.getMessage(...) where class is used as the reference point is better (at least the code itself does
not have to be changed, it is stable for package renames), but it is specific to NetBeans sources (so does not solve our
real users problem).

In all cases, moving an entry is risky since it might be used by other classes (it's hard to find out that). OTOH
copying leaves unused keys behind. Also finding all the usages of the get code patterns for all moved/copied classes
would likely slow down the refactorings significantly. And it looks like the user would have to care about the
properties file after such a change anyway...

The way the properties files and their usage is designed is simply very unsuitable for integration with refactoring.
E.g. Swing App Framework does that much better - each java file has its dedicated properties file with defined name and
relative location. Moving a java file just means moving its properties files as well. That's all. Also the auto-i18n
pattern that can be used in GUI forms allows for more deterministic moves. But the general properties files usage is

So I'd suggest:
* Not to try to correct general ResourceBundle getter code and move properties files entries accordingly.
* Not to try to fix NbBundle.getMessage use - it's for NB developers only. If you think it is needed anyway, file issue
on API support.
* Fix form's auto-i18n support to handle moves between projects - I suspect it fails now.
* Fix form not to generate "null" in case it cannot find the properties file.
* RFE: make form move i18n values in more cases than just the auto-i18n pattern, e.g. if the value comes from a
properties file in the same package as the form itself.
Comment 4 David Konecny 2008-10-15 21:18:34 UTC
Re. "Fix form not to generate "null" in case it cannot find the properties file" - this still qualifies for P2 and I
filed it as separate issue 150287.

I do agree that it is difficult to implement refactoring of properties used by form. My view is that we should at least
try and do our best, possibly issue some refactoring warnings to user and let them decide in refactoring preview. I was
refactoring several J2EE projects and was moving forms around a bit and IDE was totally unhelpful and sometimes I was
better moving files outside of IDE and do search/replace instead (issue 150287). Try it yourself and you will agree with
me. :-) I had to move properties between bundles by hand and I did not know either whether a property can be safely
moved and should be copied - again no help from IDE so I had to use search most of the time. It is not surprising I
caused handful of P2s because of MissingResourceException. How could IDE help me prevent them:
* Show Unused Bundle Keys in my project- even if it is not 100% correct
* Show Missing Bundle Keys in my project

As for refactoring: something is better than nothing. In my J2EE projects usecase let say I had to do 50 changes in
total by hand. I would be much happier if IDE did 30 or 40 of them for me. As of NB6.5 IDE screws up during refactoring
and increases the number of changes I must do to at least 80! Thanks for the help I will use you again. :-) Would I mind
waiting little bit longer to get my source refactored properly? No!
Comment 5 Jana Maleckova 2008-10-30 15:57:35 UTC
*** Issue 151759 has been marked as a duplicate of this issue. ***