It can't and it shouldn't, it's a deliberate design decision of japi.
There's absolutely no possible conceivable way for japi to know that a
particular method *needs* to be overridden, because overriding a
method or not is purely an implementation decision.
For example, at first glance it's "obvious" that String needs to
override the equals method of Object. However, it could be that for
some bizarre optimization reason a particular implementation of the
Java API might want to do something like this:
public class Object {
...
public boolean equals(Object o) {
if (this instanceof String) {
// something special
} else {
return o == this;
}
}
}
in which case String wouldn't need an override at all. This is a silly
example because nobody would ever do it that way, but there are a lot
of methods in the API which might or might not need to be overridden.
Sometimes the behavior is identical so overriding isn't strictly
necessary but the subclass can provide a faster implementation.
Sometimes instead of an override the implementation might merely defer
some *parts* of the body of that method to internal virtual methods.
Japi's business is to check the API and not make any assumptions about
the implementation. Otherwise we get into tricky legal territory as to
whether we're actually creating a clean-room implementation or a
derived work of Sun's copyrighted one.
In this case, obviously we do need to override to get the behavior
right, but japi isn't about testing behavior. Instead, we should add a
Mauve test that confirms that LdapInitialContext actually does what
it's supposed to do.
Stuart.
PS In case you can't tell, I write variations this email often ;)
On 2/15/06, Erwin Rol <mailinglists@xxxxxxxxxxxx> wrote:
> On Wed, 2006-02-15 at 09:36 +0100, Robert Schuster wrote:
> > Hi.
> >
> > Erwin Rol wrote:
> > > Hey all,
> > >
> > > I am trying to get Open Xchange working with gcj, and so far things are
> > > going OK. Now i ran into a problem with LDAP. OX uses
> > > InitialLdapContext(...) to create a initial context. Later it uses
> > > javax.naming.InitialContext.getNameInNamespace(...) and that always seem
> > > to throw a javax.naming.OperationNotSupportedException. After looking
> > > into the classpath source code it seems most methodes in .naming.* just
> > > throw a not supported error.
> > Ouch. You found what we call a silent stub. A method that will not show up in
> > the JAPI scores.
> >
>
> It seems the getNameInNamespace() correctly throws and
> OperationNotSupportedException because the javax.nameing.InitialContext
> does not know how about things to preform the action. The
> LdapInitialContext is the one that knows this, but LdapInitialContext
> does not have a getNameInNamespace() method, so the one of the base
> class is used.
>
> How could it be made that those methods that LdapInitialContext should
> overload show up as "missing" in the JAPI scores ?
>
> - Erwin
>
>
>
>
--
http://sab39.dev.netreach.com/
