I disagree with "Stop using Anonymous Inner classes and just bite the bullet and wait for 8." Are you going to stop development while you wait for 8 too?
Most IDEs tend to hide a little of the noise associated with anonymous inner classes and, at least, with IntelliJ, the auto-completion for things like Guava's Function are huge time savers that make it much more bearable.
Now, should you think twice before you reach for an anonymous inner class? Of course! But there are many situations in which "closures"/"functional-style" anonymous inner classes can significantly decrease the amount of code written and/or make it much clearer. Basically, it lets you stay D.R.Y. much better.
One very common situation is reusing a complicated data structure traversal, just to be able to do two different things with the same inner pieces of data. Without the ability to "pass in code" using anonymous inner classes, the way to avoid code duplication is to accumulate the final destination items in a list and return that from the traversal code, such that this intermediate list can then be fed into the two different code paths. Of course, often such a refactoring is not easy or litters the otherwise-clean traversal code with the details of the intermediate list population. If the intermediate list gets too long to fit into memory or if pagination is required, then you end up having to return an iterator of lists, etc. It just gets messy.
Contrast that with code that takes in an anonymous inner function to apply to each piece of data. Bam, it's so much simpler. Want to start paginating the traversal? No problem, the calling code is none the wiser.
Developers who've been using closures are very familiar with this style of coding. The ugly syntax of anonymous inner functions raises the bar for using them above many simpler situations, but the greater utility cannot be disputed.