Enthuware

Please explain the following requirement for LinkedHashMap as mentioned in the explanation of this question:

"you cannot simply insert the key-value again (without removing it) because a reinsertion operation does not affect the position of the pair"

what is the difference between 1st time insertion and reinsertion of the key, as relating to the position of the pair in the LinkedHashMap?

For example, If an element is at 3rd position (out of 10, say) and if you reinsert it, it will still be at 3rd position. If you remove it and then insert it, it will be at 10th position.

HTH,
Paul.

Why isn't TreeMap a good candidate for this? It would store the results in a sorted order (we can sepecify LastAccessedTime as a ordering criteria).

Where would the last accessed time be stored? There is no such field in the objects that you are storing.

This question seems a bit tricky because if you can modify the class, as described by @ACV001, it's actually simpler to achieve the solution than using a LinkedHashMap, since you wouldn't need to remove the object from the map and add it back.

It would be less confusing if the question statement said that we don't have access to that other class.

Which other class??

Class of the objects being cached.
And by "access", I mean being able to modify it.

Why would the developer of the cache class have the ability to modify the class of the cached objects? The cache developer wouldn't even know what type of objects will be cached. Would you expect the developer of HashMap to able to modify the class of the objects that will be stored in the HashMap? No, right?

That's true if we want to develop a generic class that could cache objects of any class.
I was thinking of a class to cache objects of a specific class (or set of classes) which we would have control.

Thanks for your thoughts.

I understand that the discussion has ended from your side but I am posting this response in case another reader goes through this thread.

>I was thinking of a class to cache objects of a specific class
Even if that were the case, you still wouldn't want to modify that class to facilitate caching. The business of caching is entirely orthogonal to the business of the class of the objects being cached and making the cache class depend on the code of the cached object class would be a violation of separation of concerns. It is tight coupling. An absolute no no.

HTH,
Paul.