db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dag.wan...@oracle.com (Dag H. Wanvik)
Subject Re: Code coverage for client.net package
Date Tue, 12 Jun 2012 21:57:59 GMT
Bryan Pendleton <bpendleton.derby@gmail.com> writes:

>>     This looks like a great collection of methods to focus on.
>> Actually what I meant to say was that these methods are not being
>> called in anywhere. Code inspection from my IDE revealed that
>> these methods are unused. So it might be possible to remove them.
> Even better!
> Although it is possible to do tricky things like invoking methods
> via reflection, in general the Derby codebase doesn't do that
> (there are some important exceptions, but...).
> So if your IDE believes that these methods aren't being called,
> I agree that it seems like we should be able to remove them.

I usually do a textual search as well to avoid missing those few that
are called via reflection. Note that on the server side it is not enough
to search the Java files, some classes are referenced only via
.properties files (module implementations). So I usually search
everything under "java", or, if I am certain it's not in the
"java/shared" folder, just in "java/engine". But there are even
exceptions to that: some classes are only used by tests (scaffolding),
so sometime search all inside all of "java" may be necessary, some stuff
in "java/build" is only called from Ant build.xml scripts etc.. YMMV.

I think the client side is easier, though: reflection is probably the
only pit one can fall into there, so textual search in "java/shared" and
"java/client" should suffice.


> Let's proceed on the assumption that we'll try to remove these
> unused and un-called methods, unless we can find some evidence
> that shows a reason to retain them.
> thanks,
> bryan

View raw message