<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 6, 2015 at 4:42 AM Tristan Tarrant <<a href="mailto:ttarrant@redhat.com">ttarrant@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 06/08/2015 10:30, Sanne Grinovero wrote:<br>
> On 6 August 2015 at 03:01, William Burns <<a href="mailto:mudokonman@gmail.com" target="_blank">mudokonman@gmail.com</a>> wrote:<br>
>> It seems ORM was compiled with a version earlier than Beta1 but then ran<br>
>> with Beta2? The keySet method was changed to return a subclass of<br>
>> CloseableIteratorSet with Beta2 to support distributed streams [1].<br>
><br>
> BTW that CacheSet API change looks like it was intended to be<br>
> backwards compatible? It's not, as we just realised. I you want it to<br>
> be backwards compatible you'll have to revert that API change.<br>
<br>
From the ORM version numbers (CR4) I guess we are near endgame and we<br>
MUST ensure that ORM works with both Infinispan 7.x and 8.x.<br>
Will is it possible to make the signature of the method backwards<br>
compatible ?<br></blockquote><div><br></div><div>The method is backwards compatible when compiling and running against ISPN 8.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If this is inconvenient, what can be done in Hibernate Infinispan to<br>
insulate it from this change ?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Still, I'm wondering whether hibernate-infinispan shouldn't be<br>
subclassed into multiple versions so that we can be a bit more liberal<br>
with some changes.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Tristan<br>
<br>
--<br>
Tristan Tarrant<br>
Infinispan Lead<br>
JBoss, a division of Red Hat<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote><div><br></div><div>[1] <a href="https://github.com/infinispan/infinispan/blob/7.2.x/core/src/main/java/org/infinispan/Cache.java#L329">https://github.com/infinispan/infinispan/blob/7.2.x/core/src/main/java/org/infinispan/Cache.java#L329</a> </div><div>[2] <a href="https://gist.github.com/wburns/c3d3d95483d35be4b8c6">https://gist.github.com/wburns/c3d3d95483d35be4b8c6</a></div></div></div>