Type Migration... yikes

Ok the idea of type migration kicks ass, and is certainly on the wow
factor. I am just going through an exercise of moving all Vectors to
List (with ArrayList instead of Vector) and tried to use Type Migration.
It throws a lot of exceptions during the process, and then to top it all
off, it really screws up the code!

if you had something like foo.removeElementAt(i) I get
(foo.removeElementAt)get(i)... what the heck is that? :)

Anyway, the idea is real cool, but man it needs some serious testing,
and I can't give it serious testing until the exceptions stop being
thrown. This is in the 3326 or what ever number eap we're at now.

I filed the exceptions. Did not file the messed up syntax replacement.

Too bad, I REALLY could have used this today.


Comment actions Permalink

Here's is how I did exactly that conversion (is a little complicated, but really pays off with a large source base):
1) Unpack the JDK source, and mount the unpacked folder instead of the src.jar

2) Change the source code of Vector, so that all 'old-fashioned' methods delegate to new ones and remove the 'synchronized'. (Note that the latter of course removes some thread safety, but you should not have counted on that anyway.)
E.g. make addElement unsynchronized and delegate to add():

elementAt() -> get()
setElementAt() -> set()
removeElementAt -> remove()
removeAllElements -> clear()
Use refactor inline on all of these methods. You code now uses the more modern counterparts.

3) Use "Refactor -> Use interface where possible" from class Vector to class List.

4) On each constructor of Vector, use "Refactor -> Replace constructor with factory method".
Afterwards in each factory method replace "new Vector(...)" with "new ArrayList(...)".
Then inline the factory methods again.

5) Don't forget to revert Vector to the original.

Comment actions Permalink

hehehehe... cool... still I want Type Migration to work :D



Please sign in to leave a comment.