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.
Changing the name of the Application itself with every release is a bug. The APPLICATION name (install directory, etc.) should not change. Installer could offer to move old version in order to save it, but the application should always be called NetBeans, and installed in the same place.
It is made mostly by design since a number of NetBeans users work with two (or more) versions of NetBeans at the same time.
The most common solution in such a case is to rename the OLD version, not rename the NEW version. The 'current' version should always be called 'NetBeans' and older versions renamed to NetBeans-<version number> rather than renaming *every* version.
I have been presenting this to the feedback alias for the last few days. The use-case for this is important. It is impossible to determine if NetBeans has been installed on a system, or at least is *very* expensive to determine, under the current situation. On a multi-user system, if User A (Administrator) installs NetBeans, then User B will not be able to tell if NetBeans is installed. So I have an installer that needs to determine if NetBeans is installed -- so that it can offer to install NetBeans if it is not already installed. Since there is no immutable name for Netbeans, and no reliable, well-known way to determine if NetBeans is installed. the only method is pure brute-force. And given that the name of NetBeans changes with every release, developers like me have to continually update their software every time NetBeans makes a new release -- I have had to update 3 times in the last 2 months, as NetBeans 6.5M1, M2, and RC1 were released, and will have to do it again when Netbeans 6.5 is released. The whole process will start over again when NetBeans 7.0 begins its release cycle. private static final String[] NB_NAMES = {"netbeans", "NetBeans", "NETBEANS"}; private static final String[] NB_VERSIONS = {"5.5", "5.5.1", "6.0", "6.0.1", "6.1"}; private String nbLocCheck(String dir, String suffix) { for (int x = 0; x < ConfigurationCheck.NB_NAMES.length; x++) { for (int y = 0; y < ConfigurationCheck.NB_VERSIONS.length; y++) { File nb = null; if (suffix != null) { nb = new File(dir + File.separator + NB_NAMES[x] + NB_VERSIONS[y] + suffix); } else { nb = new File(dir + File.separator + NB_NAMES[x] + NB_VERSIONS[y]); } if (nb != null && nb.exists()) { return nb.getAbsolutePath(); } if (suffix != null) { nb = new File(dir + File.separator + NB_NAMES[x] + " " + NB_VERSIONS[y] + suffix); } else { nb = new File(dir + File.separator + NB_NAMES[x] + " " + NB_VERSIONS[y]); } if (nb != null && nb.exists()) { return nb.getAbsolutePath(); } if (suffix != null) { nb = new File(dir + File.separator + NB_NAMES[x] + "-" + NB_VERSIONS[y] + suffix); } else { nb = new File(dir + File.separator + NB_NAMES[x] + "-" + NB_VERSIONS[y]); } if (nb != null && nb.exists()) { return nb.getAbsolutePath(); } } } return null; } So you can see that every time the version of NetBeans changes, the code has to be changed to add the new version, which becomes an issue for maintenance. In addition, as the number of releases increases, the amount of time/effort involved in determining if Netbeans is installed increases rapidly and unreasonably.
CC-ing Rudolf, he may be able to provide advice.
Why not use the following approach? FileFilter ff = new FileFilter() { public boolean accept(File file) { final String name = file.getName(); return name.matches("^[nN][eE][tT][bB][eE][aA][nN][sS]-[0-9]+(.[0-9]+)?" + ((suffix!=null)?suffix:"" )); } }; File [] candidates = new File(dir).listFiles(ff); As the result, in "candidates" array you will get all the netbeans installations that exist in "dir".
That's close, and I will play with it (complicated by sometimes using -, sometimes using " ", etc. in the app name). It is, in essence, just a more compact way of doing the same thing -- walk the directory examining every file. Though this is still extremely resource-intensive as it still walks the directory tree so, for machines that have a large number of files in /usr/local, or /opt, or (in the case of Mac OS X) /Applications this will be extremely inefficient and time/processor intensive. As a short-term work-around, this may at least get me out of the chase-the-latest-name-change game. Having the NetBeans installer use a syn-link of NetBeans-->NetBeans-latest-version, where the installer updates said sym-link on install/upgrade would be a better ultimate solution.
Assigned to new owner.