On 06/08/2015 10:30, Sanne Grinovero wrote:
> On 6 August 2015 at 03:01, William Burns <mudokonman@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev