I tried to use JFactor and it failed on almost everything I tried.
I mean anything that required any precondition checking. Do these guys check preconditions at all?
Simple example:
	class A{
		void m(){
			System.out.println("A::m");
		}
	}
	class B extends A{
		void k(){
			System.out.println("B::k");
		}
	}
	class Test{
		public static void main(String[] args){
			A a= new B();
			a.m();
		}
	}
Now, try to rename A::m to k. 
The tool doesn't notice that this will break your code.
Hey, if it fails on the smallest example I could come up with I would not trust it on projects larger than 20 lines.
(I tried other examples too - like I said - fails on almost all not-totally-trivial ones) --AdamKiezun

I just tried the above example in jFactor 1.0.1 and it worked for me. (i.e. it renamed the call in the main() method to k().) Perhaps they fixed it.  (1.0.1 was released early February). --StuCharlton

Please read the example again - renaming the call in the main() method to k() _does not fix anything_. Before the 'refactoring' you see "A::m" printed out and after you see "B::k". And, btw, there's no undo. So, basically there's no good way (unless you resort to VCM) to recover to your previous state (because guess what? renaming k to m will rename it in both types.) It's trivial to see it in a 15 line program - imagine using this on a system of 1000+ classes and code that you don't know. Wasn't refactoring supposed to help maintain code?
(Sure, if you have a full test suite, then you're good - it'll catch all these little things for you. But I'd still expect a little more support from a refactoring tool.) --AdamKiezun 

''Try reporting this bug to mailto:jfactor-support@instantiations.com  I have found the Instantiations folks to be very responsive.''

Hold on a minute.  Is this a bug or not?  If you rename the method m in class A to k, and class B overrides k, then you should expect the output to be "B::k", because you've instantiated an instance of B -- you just happen to be referring to it as an A.  Is this not how Java is supposed to behave? -- StevenNewton

It is a bug - my program behaves differently before and after the 'refactoring'.
Just a reminder: "a refactoring is a behavior-preserving transformation of source code". The tool should disallow the change or at least warn you that the new behavior might be different. --AdamKiezun

Okay, but "behavior anomalies" in terms of inheritance is defined by a contract, and assuming you design your classes with LiskovSubstitutionPrinciple, this should not "break" anything.  Yes, it places a trust in the programmer, so a warning may be appropriate.  Disallowing this refactoring is a bit too drastic.  Does Martin's book elaborate on something like this (renaming a method in a super)?  --StuCharlton

Martin's book ignores the case when a class or one of its subclasses understands the new message. Both BillOpdyke's and DonRoberts' theses include this precondition. And, btw, it's handled properly in RefactoryBrowser.
The point I was trying to make is that a refactoring tool should be reliable enough for me to be able to press 'finish' on the first page of the wizard and be 99% sure it'll do the right thing for me (and will warn me if it can't). The right thing being: 'not change the behavior of the program' - totally regardless of the program's using good design, naming conventions and such. --AdamKiezun

The approach we take with jFactor is to (as stated above) "place trust in the programmer" and allow things that may change the behavior of the program if so chosen by the programmer.  That said, jFactor should and does in many cases warn the programmer when the program's behavior will be changed.  This is one case we overlooked and it is now corrected in the latest beta.  We are very responsive to suggestions and comments, so by all means, if you encounter a situation that you think should behave differently, then let us know and we will immediately correct the situation.  Luckily, some kind soul notified us of this situation mentioned here and we fixed it as soon as we heard about it. -- DanRubel (mailto:jfactor-support@Instantiations.com)