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.
There is no special significance, and indeed, because methods that are private are only visible to the class itself and are not inherited by subclasses, it doesn't make much sense to make private methods final.
Note that for instance variables it's different, because the meaning of the word "final" is different: it means the value can't be changed once it's initialized (it doesn't have anything to do with inheritance).
Note that inner classes can see eachother's privates, and those of the containing class. Therefore you could cook up a scenario where an inner class (which was also a subclass of another inner class) was blocked from overriding a final private method. That's awfully far-fetched, though, and I think "there's no purpose for it" is a fine answer in general.
I just finished a project that has your exact example Ernest, except with an attribute and a class
The outer class is called SymbolTable and the inner nested class is called TableEntry, and the symbol table is made up of entries. SymbolTable only has one attribute which is a private final HashMap. And the only way I wanted the HashMap to be modified was from the SymbolTable class
Shortened Code Below:
Hope this helps,
"If the facts don't fit the theory, get new facts" --Albert Einstein