Hi Bob,
I think I preferred my previous teacher as he at least doesn't give you
the feeling you ask stupid questions all the time :-P
Bob Scheifler wrote:
Mark Brouwer wrote:
1) Going through the source of the contributed services to see which
other proxies provided by Seven should take advantage of ReferentUuid I
noticed that for Reggie the decision was made to have
com.sun.jini.reggie.Registration implement ReferentUuid, while for the
other type of registrations (events) it was decided that they don't
implement ReferentUuid, what is the rationale behind that decision?
Not sure what you have in mind, EventRegistration isn't a proxy interface.
I have nothing particular in mind, I try to understand when and why
to implement ReferentUuid and I have no neural network in place yet that
when that question goes in, the answer flows out automatically with full
confidence. So far I get the impression it is important because some
specs require reference equality that is currently
specified to be answered through equals of an object/proxy/source and
ReferentUuid is a robust tool for that. Maybe when ReferentUuid was
invented in 1999 those specs would have been different and clients would
have drawn reference equality conclusions instead of letting an equals
decide, but I believe that is the answer of which I can have an opinion
but is really for you and others to say ;-)
One could say that for both EventRegistration and ServiceRegistration
(implemented by com.sun.jini.reggie.Registration) the resource it
represents is covered by the associated Lease and as such there is no
need for ReferentUuid to be implemented by Registration at all, but
nevertheless it has been decided so. It is even so that when looking
at the code I see that equals of Registration delegates to the lease
which seems to confirm what I believe is the case.
As such I would have expected EventRegistration to have an
equals/hashCode as well and to find it normal to have it (a subclass of
course) to implement ReferentUuid.
Currently in Seven I have a subclass of EventRegistration that has an
additional reregister method (performs a remote method call) and it
implements RemoteMethodControl. So maybe now it could be seen as acting
as what you would call a proxy and should I suddenly start using
ReferentUuid here, but if EventRegistration doesn't need it, why should
the subclass suddenly need it? I find this hard to reason about given
the absence of a spec that requires reference equality for these event
registrations.
2) Why don't the equals implementation at least check whether the object
passed in for the test of equality implements the same interface.
Because that would introduce the defined-in-different-class-loaders
problem that you're trying to avoid.
Maybe I didn't make that clear but I was referring to those objects for
which it is assumed the primary interface is part of the platform, such
as can be assumed for Lease and TransactionParticipant, etc. similar as
that ReferentUuid must be in a Platform to make it work too. So I
decided to implement the equals for a LeaseProxy as below:
public boolean equals(Object obj) {
if (obj == this) {
return true;
}
else if ((obj instanceof Lease) && (obj instanceof ReferentUuid)) {
return uuid.equals(((ReferentUuid) obj).getReferentUuid());
}
return false;
}
Assume you have a main proxy and its associated administration proxy
both implementing ReferentUuid, in that case the equals of the main
proxy will be along the lines of:
public boolean equals(Object obj) {
if (obj == this) {
return true;
}
else if ((obj instanceof Administrable)
&& (obj instanceof ReferentUuid)) {
return uuid.equals(((ReferentUuid) obj).getReferentUuid());
}
return false;
}
This will at least return false in case you compare the main proxy and
administration proxy (assuming it doesn't implement Administrable) even
while their Uuid as returned by getReferentUuid() are equal.
Maybe it is completely logical that the answer should be true here, but
somehow I can't get a grip on why it should.
--
Mark
