Eric & Sree- I can write an example of an abstract local class, but I can't really come up with any example where it would actually be
useful for anything. An abstract class can't really be useful unless you're going to create at least two other classes that implement it - if there's just one, then why bother putting some functionality in the abstract class and some in the concrete subclass? Just put it all in the one class. And the abstract local class is only in scope inside the method it's defined in - so the only place to implement other classes which extend it, is inside the same method. So we're talking about at least three separate local classes inside the same method, in addition to the code that actually uses the classes. Ugh! That's going to be an unreadable nightmare. Methods should be kept short for readability. All those local classes would work much better as top-level classes or member classes, defined somewhere outside the method where they won't create such confusion. If the classes need access to some local variables, then create methods that allow the variable value to be passed.
Actually, I feel much the same about most local classes. Anonymous classes can be OK if they're short, but named local classes take up too much space inside a method. You
can use them, but in most cases you probably shouldn't.
Anyway, abstract classes are legal, and local classes are legal, and so abstract local classes are legal because there's no fundamental reason why they should be impossible - they're just undesireable, in my opinion.
As for Eric's second question- no. I don't believe it's ever possible to instantiate
any local class from outside the method that defines it, much less outside the
class that defines it.