About stub methods

[Mark Wielaard]

Hi,

Please Stop arguing about how the framework for handling unimplemented
classes and stub methods should work. I know it is the ideal "What color
should the Bike Shed have" discussion (*), but stub methods are a bad
thing to have and should just be treated as grave bugs.

Having those method because they allow people to compile against GNU
Classpath but not run against it really doesn't make much sense. Let
people fix either their code or help us implement the missing
functionality.

If you find such a method in the source please just remove it and file a
bug report about it (possibly with as bug message the partial
implementation). Or better just implement it! If there really is a
strong reason to have that particular method as a stub method then we
should do that in the simplest possible way that makes it easy to
quickly find those methods in the source. That means that it should be
some standard string that people can easily grep for all on one line.

Note that as said above making things compile, but not run with GNU
Classpath is not a strong reason. So you should really be able to point
to a free software program written in java that would just need one
little stub method to be completely usable with GNU Classpath to justify
having something as a stub method.

The first person to actually volunteer to go through more then a handful
of classes to remove (silent) stub methods gets to decide what the
actual "Not Implemented" line says (and whether it is an Exception or an
Error, an existing class or a new class). Who actually want to do this
work?

And if whole classes or packages are stubby then we are better off just
removing them or at least add them to the lib/standard.omit file so they
won't appear in our release till we can offer real functionality for
them.

Thanks,

Mark

(*)
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING

signature.asc
Description: This is a digitally signed message part