From derby-dev-return-96440-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Tue Jun 12 21:58:35 2012 Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 174F0957D for ; Tue, 12 Jun 2012 21:58:35 +0000 (UTC) Received: (qmail 38048 invoked by uid 500); 12 Jun 2012 21:58:34 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 38022 invoked by uid 500); 12 Jun 2012 21:58:34 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 38014 invoked by uid 99); 12 Jun 2012 21:58:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jun 2012 21:58:34 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dag.wanvik@oracle.com designates 141.146.126.227 as permitted sender) Received: from [141.146.126.227] (HELO acsinet15.oracle.com) (141.146.126.227) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jun 2012 21:58:25 +0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5CLw2hZ022730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Jun 2012 21:58:03 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5CLw1kE015872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Jun 2012 21:58:02 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5CLw1PM019942 for ; Tue, 12 Jun 2012 16:58:02 -0500 Received: from localhost (/10.175.59.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Jun 2012 14:58:01 -0700 From: dag.wanvik@oracle.com (Dag H. Wanvik) To: Subject: Re: Code coverage for client.net package References: <4FBB9DA2.20906@gmail.com> <4FBC26CF.1040500@gmail.com> <4FBC5F02.2010400@gmail.com> <4FC0EDF0.1060303@gmail.com> <4FD3A6A6.8020409@gmail.com> <4FD5FD81.3050209@gmail.com> <4FD6842E.40408@gmail.com> Date: Tue, 12 Jun 2012 23:57:59 +0200 In-Reply-To: <4FD6842E.40408@gmail.com> (Bryan Pendleton's message of "Mon, 11 Jun 2012 16:50:06 -0700") Message-ID: User-Agent: Gnus/5.110017 (No Gnus v0.17) Emacs/24.0.96 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Bryan Pendleton 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. Dag > > 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