I'm not sure I quite follow ;-) There was a bug in the 3.0 LRUMap which
caused the wrong map entry to be passed to the protected method handling
deletion. However this is fixed in CVS. The test case you show is the test
for the bug, and demonstrates that LRUMap can exceed its size.
The protected restriction on the LinkEntry fields is another problem fixed
in CVS - see the entryAfter() and entryBefore() methods.
Stephen
----- Original Message -----
From: "Mario Ivankovits" <[EMAIL PROTECTED]>
> I tried to use the map.LRUMap but failed by a design issue.
>
> Copied from the test-case:
>
> MockLRUMapSubclassBlocksRemove map = new
> MockLRUMapSubclassBlocksRemove(2);
> assertEquals(0, map.size());
> map.put("A", "a");
> assertEquals(1, map.size());
> map.put("B", "b");
> assertEquals(2, map.size());
> map.put("C", "c"); // should remove oldest, which is A=a, but
> this is blocked
> assertEquals(3, map.size());
> assertEquals(2, map.maxSize());
> assertEquals(true, map.containsKey("A"));
> assertEquals(true, map.containsKey("B"));
> assertEquals(true, map.containsKey("C"));
>
> The interesting part is "map.put("C", "c"); //* should remove oldest,
> which is A=a, but this is blocked*".
> Even it the current test-case do not handle it (it blocks all entries),
> but shouldnt the LRUMap - if an entry is locked - search the next
> removeable entry?
> At the end, the entries "A" and "C" should be in the map - only if all
> entries are lock the map should grow.
>
> I cant derive from LRUMap to overload addMapping - The members "before"
> and "after" on LinkEntry are protected and not accessible by the subclass.
>
>
> -- Mario
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
