R. Jain

Winston Gutkowski wrote:

R. Jain wrote:I'm afraid Jesper, but I've to disagree with you on this. You can add BigCats or any of it's subtypes to such lists. Right?

Wrong.
And, as he says, since the compiler doesn't know what that type is; it can't allow you to add anything.
Winston

That is true for the Collection<? extends T>. But for Collection<? super T>, I can add an instance of subtype of T to it right? I understand that we're talking about homogenous structures here, and that the collection at the end will be holding a specific type. But type widening is what I'm refering to here, while adding a subtype of T.
Did I misunderstand something?

Jesper de Jong wrote:The same with List<? super bigcats>. The compiler doesn't know what the exact type is of the elements in the list - it only knows that it's something that is a superclass of bigcats. You can't add anything to that list, for exactly the same reason as above.

I'm afraid Jesper, but I've to disagree with you on this. You can add BigCats or any of it's subtypes to such lists. Right?

The key here is to understand the term PECS (Producer Extends Consumer Super). That simply means that a Collection<? extends T> is a producer of T, and a Collection<? super T> is a consumer of T.
Now when I say producer or consumer of T, that also applies to the subtypes of T, but not to the supertype of T. For example, a List<? super Dog> can take a Dog or it's subtype, but not Animal. Basically because a List<? super Dog> means a list of any type that is a super type of Dog. Surely you can add a Dog or it's subtype to any such list. But suppose you've your class declaration like this:
interface Barkable { } class Animal { } class Dog extends Animal implements Barkable { }
Then certainly the following shouldn't be allowed:
List<? super Dog> list = new ArrayList<Barkable>(); list.add(new Animal());
else you're saying that any Animal has Barkable behaviour, which is not really true.

So just remember - PECS.

Raymond Gillespie wrote:They are String objects.

But your for loops says, it's Items.

I'm afraid that wouldn't be possible. But suppose even if it was possible, and you created `Builder` instance of super class. Then how would you set attributes for subclasses? Wouldn't be possible right? Only Builder class specific to subclass will do it.

Also, if your super class is abstract, you should also make your super `Builder` class abstract. Else, which object would you expect it's `build()` method to create?

So in those cases, the advice would be applied as and when the respective join points are encountered?

Jayesh A Lalwani wrote:The docs say that the ordering of advices in the same aspect is undefined.

Yeah, but what if the advices are on different join points? The documentation is specifically stressing on same join point.

I've an aspect class like this:
@Aspect public class TransactionLoggingAspect { @Around("pointcut_1()") public void advice_1(ProceedingJoinPoint proceedingJoinPoint) throws Throwable { } @After("pointcut_1()") public void advice_2() { } @Around("pointcut_2()") public void advice_3(ProceedingJoinPoint proceedingJoinPoint) throws Throwable { } @After("pointcut_3()") public void advice_4() { } }

My concern is what will be the order of execution of those advices? For example, is advice_1() always guaranteed to execute before advice_2(). Note both are on same join point. What about the ones on different join points? advice_2() and advice_3()?

Good. Now you've setup the skeleton of your ValueComparator. Moving forward, what do you think you would need in order to compare the values in the compare() method? You know the String arguments are keys and not the values themselves. So how are you going to get the value for those keys?
HINT: You already have the map in your ValueComparator class. So, if I give you a map key, how would you get the value for that key in the map? Add code for this in your compare() method.

Once you are able to get the values, whose type is List<Bean>, for both the keys, you can then move ahead with actually comparing those lists.

You're only writing the same text of question and again and again, and are not showing the modified ValueComparator. Try to read and understand my last response. I'm not going to give you the complete solution. You've to come up with that on your own. I'll just help you with that. I'm saying it again - can you try implementing the Comparator<String>. You seem to be thinking that, it will be used for comparing keys. But, you can also use it to sort map on value. You just have to use Map#get(key) method to get the value for both the keys.

What are you confused about? Did you try modifying the ValueComparator to implement Comparator<String>? In that case, the compare() method will take 2 String arguments, which will be 2 keys in your map. Since you already have the map in your ValueComparator class, just get the value for both the keys, and compare them accordingly.

Oops! It was my mistake. ValueComparator should implement the Comparator<String>, which is the key here.

What error are you getting?
P.S: Please don't edit your post, as further reply becomes meaningless. Rather add a new post with modified code.

You should implement a parameterized instance of Comparator, rather than using raw type, which you're doing currently. So, change your ValueComparator declaration to:
public class ValueComparator implements Comparator<List<Bean>> { } // Or whatever type is the value in your map.
Also, change all the raw type usage of Map with parameterized instantiation. You should not use raw types in newer code.

jegadees waran wrote:I knew the values should be of type string for the comparable to Work

Where did you read that? It's not the case. You can have Comparator of any type, as in above declaration.

Ah! After spending half-an-hour in JLS and JVM Spec, I finally found the reason there in JLS Section 14.20.2 , specifically these lines:

If execution of the try block completes abruptly because of a throw of a value V, then there is a choice:
[...]
If the run-time type of V is not assignment compatible with a catchable exception class of any catch clause of the try statement, then the finally block is executed. Then there is a choice:

If the finally block completes normally, then the try statement completes abruptly because of a throw of the value V.

If the finally block completes abruptly for reason S, then the try statement completes abruptly for reason S (and the throw of value V is discarded and forgotten).

And the return statement in the finally block results in abrupt completion of the finally block. See JLS Section 14.17 - return Statement, lower down the section:

It can be seen, then, that a return statement always completes abruptly.

So, the second rule in the above list is applicable here. Since finally block completes abruptly due to a return statement (Reason S), the try statement completes abruptly because of that return statement. And hence your method returns 0.

Lesson of the day: You should never ever return from a finally block, else be ready for surprises