Bug 30140 - Code migration tool
Code migration tool
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: Refactoring
4.x
All All
: P3 (vote)
: 7.1
Assigned To: Jan Becicka
issues@java
: PLAN
Depends on: 197193
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-15 14:52 UTC by _ pkuzel
Modified: 2011-09-12 07:16 UTC (History)
6 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2003-01-15 14:52:48 UTC
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 :-).
Comment 1 Jesse Glick 2003-01-15 15:14:50 UTC
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.
Comment 2 Martin Matula 2004-11-13 21:32:59 UTC
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.
Comment 3 mikeskells 2005-06-08 09:16:05 UTC
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
Comment 4 stuart_marks 2011-06-10 23:02:57 UTC
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
Comment 5 stuart_marks 2011-06-10 23:22:07 UTC
More new APIs:
 - java.util.Objects (requireNonNull etc.)
Comment 6 Jesse Glick 2011-06-22 13:35:52 UTC
(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.
Comment 7 Jan Becicka 2011-09-12 07:16:14 UTC
We have "Inspect and Transform" feature in 7.1.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo