[infinispan-dev] Hibernate ORM 5.0.0.CR4 not working so well with Infinispan 8.0.0.Beta2...

[William Burns]

On Thu, Aug 6, 2015 at 4:42 AM Tristan Tarrant <ttarrant at redhat.com> wrote:

>
>
> On 06/08/2015 10:30, Sanne Grinovero wrote:
> > On 6 August 2015 at 03:01, William Burns <mudokonman at gmail.com> wrote:
> >> It seems ORM was compiled with a version earlier than Beta1 but then ran
> >> with Beta2?  The keySet method was changed to return a subclass of
> >> CloseableIteratorSet with Beta2 to support distributed streams [1].
> >
> > BTW that CacheSet API change looks like it was intended to be
> > backwards compatible? It's not, as we just realised. I you want it to
> > be backwards compatible you'll have to revert that API change.
>
>  From the ORM version numbers (CR4) I guess we are near endgame and we
> MUST ensure that ORM works with both Infinispan 7.x and 8.x.
> Will is it possible to make the signature of the method backwards
> compatible ?
>

The method is backwards compatible when compiling and running against ISPN
8.

I don't think there is any way here to make this backwards compatible
changing only ISPN with varying versions at runtime without adding new
methods in ISPN 8 which are identical to keySet, values and entrySet except
the return type for them are defined as returning the new
CacheSet/CacheCollection interfaces.  The underlying implementation for the
duplicates would be identical however.  Without those new methods we
wouldn't have access to the more advanced options when using distributed
streams unless we manually casted.  This doesn't sound too appealing to me.


> If this is inconvenient, what can be done in Hibernate Infinispan to
> insulate it from this change ?
>

This code is essentially doing a clear, but can this code live with the
semantics of clear [1] that are the same between ISPN 7 & 8?  I am guessing
not.

We could add a utility method in ISPN 7 & 8 that is defined as returning a
ClosebaleIteratorSet/Collection that would be identical in both versions
that we could also do [2].  Then if ORM calls the appropriate static method
instead of keySet, values, entrySet it would be backwards runtime
compatible as well.


>
> Still, I'm wondering whether hibernate-infinispan shouldn't be
> subclassed into multiple versions so that we can be a bit more liberal
> with some changes.
>

This does hamper changes quite a bit.  This change was pretty minor, I
can't imagine if they are using some class/method that we are removing in
ISPN 8.


>
> Tristan
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


[1]
https://github.com/infinispan/infinispan/blob/7.2.x/core/src/main/java/org/infinispan/Cache.java#L329

[2] https://gist.github.com/wburns/c3d3d95483d35be4b8c6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150806/a5698c91/attachment-0001.html