This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
In that situation x would need to be final because it is a method local variable that normally would be cleaned up from the stack as the method returns. Your inner class has a reference to it, and basically (although I don't really understand the details), the final allows the compiler to give you a copy of the value that your class can use. For object references, the compiler needs to know that the object your reference refers to will not be changed.
When you make the variable final, instead of placing the value of x in the stack for method1 (which gets zapped as soon as the method is over) the variable value gets put in the Constant Pool which sticks around and is therefore available so that the m object can use it even after method1 is over. In this case that is not much of a deal because as soon as method1 is over the the object referenced by m is available for the GC, however it is possible for such a method to return such an object or to have a variable outside the method hold a reference to it. In that case the MyClass object could live for a LOT longer than the method in which it was created.
"JavaRanch, where the deer and the Certified play" - David O'Meara