Hi,

Making this change seems like the right thing to do. While it changes the 
formal signature of the SingleFieldIdentity API class, no one will notice it 
unless (SignatureTest) they go  looking for it.

We just need to be careful. If there are concerns, we might consider putting 
this into 3.3 without going into a possible 3.2.2 release.

But I don't see anything amiss in the approach Michael suggests.

Regards
Craig

> On Aug 9, 2022, at 06:28, Michael Bouschen <m...@apache.org> wrote:
> 
> Hi,
> 
> as part of JDO-817 "Check Compiler warnings" I was looking into the warnings 
> of the api submodule. I started with "raw use of parameterized class", so 
> replacing the use of Set by something like Set<String>.
> 
> There is one case where I need some feedback. In javax.jdo.identity there is 
> a class SingleFieldIdentity which is the abstract base class for single field 
> identity classes such as IntIdentity, LongIdentity, etc. Today the abstract 
> base class implements Comparable without implementing method compareTo which 
> is done in the subclasses. The implements clause is using the raw type 
> Comparable.
> 
> I would like to fix this and move the implements clause to the concrete 
> subclasses, e.g.:
> 
> public class IntIdentity extends SingleFieldIdentity implements 
> Comparable<IntIdentity>
> public class LongIdentity extends SingleFieldIdentity implements 
> Comparable<LongIdentity> 
> This way we can use the concrete subclass as class parameter for Comparable.
> 
> Then the signature of the compare method takes an instance of the concrete 
> subclass as an argument instead of Object, such that we do not need the 
> instanceof check anymore:
> 
> public int compareTo(LongIdentity o) {
> 
> instead of
> 
> public int compareTo(Object o) {
>    if (oinstanceof LongIdentity) {
>    
> The TCK succeeds with this change, but we would need to change the 
> SignatureTest (runonce.conf), because of the change of the implements clause 
> of SingleFieldIdentity and its subclasses.
> 
> What do you think? Is this an API change that is OK?
> 
> Regards Michael

Craig L Russell
c...@apache.org

Reply via email to