Database Software

Because Comparator is an interface, not a class. What you did the second time around was flesh it out.

Edited by: abillconsl on Mar 29, 2011 2:35 PM

IOW: compare must be implemented.

More precisely, it's because Comparator is abstract (as are all interfaces), and the anonymous inner class is concrete, with implementations for all of Comparator's abstract methods. The exact same behavior occurs with abstract classes, and for the exact same reason. :-)

Oh ok. That makes sense. Just curious. The second block that I wrote is an anon class???

Not exactly anon with the named variable SENIORITY_ORDER that you can use as a handle to call compare on it though.

The 'second block that he wrote' is indeed an anonymous class. Please don't just create confusion.

Yeah, it's anonymous. Having a variable refer to it doesn't change that. It's the fact that the class itself is defined inline and has no name that we can use to refer to it that makes it anonymous.

Of course you're both right, the class has no name - that's the important point. I didn't mean to confuse anyone, and I apologize.

OP, probably, usual practice is that anon classes are declared without a reference variable attached: As opposed to: Looking at the compiled .class names will usually show though, that, as opposed to a true local class coded more like this: - that has a name: The anon class will likely be named as: Thus the lack of a class name.

I disagree. I don't have solid numbers, but I do know that in my own case, a pretty significant number of my anonymous classes to get a reference variable attached by me at the point I declare them. And even if I don't assign the reference to a variable, whatever I hand that object off to will.

The way I phrased my reply allows anyone to freely disagree, without hard facts. What I meant was simply that in most of the cases a beginner will see - via tutorials for example - will likely be the w/o the ref variable. I say likely, only because that is my own experience. Again, anyone is obviously free to disagree.

Except in the other cases. I fail to see the relevance of this remark. His question is about 'comparator object instantation', and this is a perfectly legitimate way to do it, if the Comparator is stateless. The way you phrased your reply was that your statement was 'probably' true, and it was indeed 'without hard facts' of your own. Dubious and irrelevant.

Simple answer is: you don't.
This works too:

static final class SeniorityOrder
       implements Comparator<Product>{
   public SeniorityOrder() {}
   public int compare(Product e1, Product e2) {
      return 1;
   }
};

And then whenever you need one, use 'new SeniorityOrder()'. I hope that isn't your actual comparison method though :-).

Winston