Minor Release 3.9.0 - Available

[boaks]

See 3.9.0.

[sbernard31]

I know it's a bit a kind of stupid question, but do you think there is some risk of regression or behavior change in this release OR this is just a very minor release with mainly some small fix ?

[boaks]

That depends ...

The main change is the switch from LeastRecentlyUsedCache to LeastRecentlyUpdatedCache. I use the LeastRecentlyUpdatedCache now for more than a year without issues. But never say never.

[boaks]

The 3.9.0 is released and available on the Eclipse Repository.

The tools and actinium are also available on the Eclipse Repository.

The 3.9.0 is released is also pushed to Maven Central but it will take some time, until it gets available there.

[boaks]

The 3.9.0 is now also available on Maven Central.

[sbernard31]

The main change is the switch from LeastRecentlyUsedCache to LeastRecentlyUpdatedCache. I use the LeastRecentlyUpdatedCache now for more than a year without issues. But never say never.

with 3.9.0 LeastRecentlyUsedCache seems deprecated and so Predicate is deprecated too.

I have some code which using it and would like to know how to adapt to not use deprecated code ?

See :

https://github.com/eclipse-leshan/leshan/blob/master/leshan-server-cf/src/main/java/org/eclipse/leshan/server/californium/ConnectionCleaner.java#L42-L47

[boaks]

That's seems to be a very nasty dependency in the API. That set of methods depends on the implementation of the
connection store. I've overseen that.
I don't see a easy fix. Adding the methods using twin API of the new implementation will not be easy to use, but I guess it will be the fastest work-around.

[sbernard31]

Adding the methods using twin API of the new implementation will not be easy to use, but I guess it will be the fastest work-around.

I understand that user will need to call 1 API or another depending of version of used LRU cache ?
If that so, I strongly encourage to search another solution.
OR the new implementation will support both cache ?

[boaks]

I investigated more. It's a java 7 rudiment, using java 8 it could be replaced in the API by Function<Connection,Boolean>.

So using the old ones works but reports the "deprecation warning". Otherwise the unit tests would have failed.
Adding new ones with LeastRecentlyUpdatedCache.Predicate<Connection> works then without that warning.
And once switching to Californium 4 and at least java 8, the API could be cleaned up.

[sbernard31]

I looked at the code and I understand there is strictly no reason to reuse LeastRecentlyUsedCache.Predicate for those methods ?
I was thinking that the Predicate instance was passed to LeastRecentlyUsedCache or LeastRecentlyUpdatedCache, but I think this is not the case so it should be better to create a dedicate class (or another dedicated) and so

Adding the methods using twin API of the new implementation will not be easy to use, but I guess it will be the fastest work-around.

Could work as short term workaround (waiting v4.0.0)

[boaks]

it should be better to create a dedicate class (or another dedicated) and so

Yes, or half yes.
I think, using the java sdk class will be the the best. But therefore we need to update.
We can now also introduce an independent interface, but if that gets the replaced, the win isn't that large.
But maybe, though some change may take longer, we try to use a separate Predicate.

I will try that out next week.

[boaks]

PR #2165 handles the deprecation by introducing a separate interface Filter.