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.
While starting NB a lot of "Clients of obsoleted Open APIs are encouraged ..." warnings are logged. One can imagine that we could save routine work for many developers by providing a tool that transforms current API calls to new API calls. I can imagine a tool that can read a mapping file provided by API change author. For TopManager API change we need to map: - one static method to another - instance method on singleton to static method - update imports Yes, a kind of refactoring :-).
1. RefactorIt! already does just this, FYI. 2. perl -pi.bak -e 's/\b(org\.openide\.)?TopManager\.getDefault ?\(\)\.getErrorManager\b/org.openide.ErrorManager.getDefault/g' `find * -name \*.java -print` etc. 3. Not so hard manually anyway. (a) Remove openide-deprecated.jar from build.xml:compile:<classpath>. (b) Press F6. (c) Press F12. (d) Correct. (e) Repeat (c) as needed. (f) File -> Save All.
Capability of providing a description of a refactoring in a declarative form and performing that refactoring could be a nice feature of refactoring module. Code manipulation for migration of old APIs to new ones could also be handcoded on top of the new javacore API in apisupport module.
surely the rename should be done as part of the @depricated tag, or some new tag, or attribute You could add a @replaceCall tag that is more explicit, that would allow the refactoring/tasklist module module to suggest, and implement a change. If this is done then upgrading the sources would work for user code as well as NB code, and could also be done where the source is not available
We keep having conversations about some kind of automated or semi-automated code migration feature in NetBeans. It seems a reasonable place as any to try to capture information about this feature in this bug report. I have some experience with Jackpot in upgrading the JDK to use Java 7 diamond and try-with-resources. This is OK so far as it goes but it would be really great to have this integrated directly with NB. In fact it's probably necessary for uptake of Java 7 features to have this feature directly in NB. Currently there is support for this in NB, but it takes the form of a "lightbulb" hint in the left margin of the code editor. This works well if you happen to be looking at some code where a new Java 7 feature can be used. What's really needed is a batch update function that scans the code base (open projects, open files, or whatever) and gives the user a list of potential locations where the new feature could be applied. This would be like the "Tasks" or the "Find Usages" window. The user could then navigate to each location, apply an automated refactoring (if available), and possibly do some manual editing. It also seems likely that there should be a way to mark a location as not being suitable for a refactoring or migration or whatever. (This might, for example, take the form of some kind of markup in a comment.) This would be helpful so that the location doesn't keep reappearing in the batch update list and forcing the programmer to revisit code that's already been visited. (This might also turn off lightbulb hints at that location.) Migration or batch update applies both to new language features, new APIs, and javadoc markup. Lists of each of these are given below. I imagine that there ought to be a preferences setting to enable or disable each of these, possibly on a per-project basis. These lists merely contain what I happened to think of. Not all of these are necessarily useful. I've probably missed some as well. Language Updates - generics - enhanced for-loop - asserts (for "should never happen" comments) - @Deprecated (add annotation if @deprecated occurs in javadoc) - enums - strings-in-switch (Coin) - multi-catch & precise rethrow (Coin) - try-with-resources (Coin) - safe varargs (Coin) - enhanced numeric literals (Coin) - diamond (Coin) API Updates - exception causes (when throwing from catch block) - NIO Files and Paths utilities - NIO File instead of java.io.File - StringBuilder instead of StringBuffer - printf instead of println(s1+s2+...) - Hashtable => HashMap, Vector => ArrayList Javadoc Updates - replace <code>foobar</code> with {@code foobar} - replace @exception with @throws
More new APIs: - java.util.Objects (requireNonNull etc.)
(In reply to comment #4) > It seems a reasonable place as any to try > to capture information about this feature in this bug report. https://bitbucket.org/jlahoda/jackpot30/wiki/Home would be more appropriate for discussions of a user-extensible tool. > it takes the form of a > "lightbulb" hint in the left margin of the code editor. This works well if you > happen to be looking at some code where a new Java 7 feature can be used. > What's really needed is a batch update function that scans the code base (open > projects, open files, or whatever) and gives the user a list of potential > locations where the new feature could be applied. bug #135014 > It also seems likely that there should be a way to mark a > location as not being suitable for a refactoring or migration or whatever. > (This might, for example, take the form of some kind of markup in a comment.) Generally @SuppressWarnings is used for this purpose. > - StringBuilder instead of StringBuffer There is already a standard hint for this.
We have "Inspect and Transform" feature in 7.1.