Robert Klemme wrote:
On 05.06.2007 12:00, djbaker2 wrote:
Cool, thanks. I use netbeans, but this is code wrote by someone else.
They claim that they have had it compiling in the past but they can't
have done because there is this class that doesn't implement the
necessary methods. I was just wondering if there was a way they could
have got around it.
Well, you can - in a way: define an interface, create a class that
implements all methods of that interface, add methods to the interface
but do *not* recompile the class.
Practical example, java.sql interfaces were extended during the course
of JDBC evolution but you can still use an old JDBC driver even with a
newer JDK if you constrain yourself to the old methods. The will
application run perfectly until a non implemented method is invoked in
which case you will get an error (NoSuchMethod error I believe, but
could also be one of AbstractMethodError and
IncompatibleClassChangeError).
Another dodge that is not a mistake is to use an abstract implementation
of the interface, typically one whose methods do nothing or throw
UnsupportedOperationException, then derive the "real" classes from the
abstract class.
interface Foo
{
void method();
}
abstract class AbstractFoo implements Foo
{
public void method()
{
return new UnsupportedOperationException();
}
}
class ReallyDoesFoo extends AbstractFoo // should compile without error
{
}
You see this in the Collections framework (AbstractList, ...)
Yeah, true. Rereading the original posting this also seems a possible
scenario. I had assumed that the method were plain missing. Thanks!