On 10 July 2013 11:32, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 9 Jul 2013, at 20:22, Sanne Grinovero <sanne(a)infinispan.org> wrote:
>>> ConcurrentMap adds a load of pitfalls which should not be there: all
>>> the methods whose result is depending on the node they are run on.
>>>
>>> I know we make it clear in javadocs and several warnings on the doc,
>>> but experience tells that this is not good enough :-(
>>>
>>> I'd propose to remove them all, and provide an adapter layer
>>> (optional) for those needing to replace a ConcurrentMap in their code.
>>> Methods like "size()" - as discussed before - are possibly useful
for
>>> statistics and diagnostics, and therefore should be accessed in a
>>> different explicit way.
>>>
>>> cache.diagnosticsStatistics().localContainerSize()
>>
>> +1. That would be part of the migration towards to JCache API and implemented in
7.0. I think Tristan was looking for something now.
>
> I see. But since we plan a change anyway, why not doing the right
> thing right away?
That would making Cache not implement the j.u.ConcurrentMap interface but a new
interface, potentially the one exposed by JSR 107. Whilst the timing is good (new major) I
think that is a rather large change in the context of the already very busy 6.0 and not as
important as other features or stability. There's also JDG backward compatibility. I
guess Tristan can comment more on the effort needed for implementing such a change.
Fair enough. I just assumed you where discussing about breaking the
backwards compatibility, if not that's very welcome.
> Ok we can change interfaces on mayor versions, still
> the less you change them the better: any change is a big pain for
> other projects.
This is not that much a change in method signature but only moving methods around to
separate interfaces.
That sounds like it still breaks backwards compatibility.. possibly I
have not understood how you envision that.
Cheers,
Sanne
>
> Unless Tristan was looking for something backwards compatible right
> now? Of course I'd prefer that, I was making suggestions assuming the
> interface chain would change now in some non-compabile way.
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev