Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4315E478.5060107@debrunners.com>
Date: Wed, 31 Aug 2005 10:10:16 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: [jira] Commented: (DERBY-496) unit test
 'org.apache.derbyTesting.unitTests.services.T_Diagnosticable'
 was failed
References: <1888682419.1125486186316.JavaMail.jira@ajax.apache.org>
In-Reply-To: <1888682419.1125486186316.JavaMail.jira@ajax.apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tomohito Nakayama (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-496?page=comments#action_12320680 ] 
> 
> Tomohito Nakayama commented on DERBY-496:
> -----------------------------------------
> 
> Description of DERBY-496_2_addition.patch:
> 
> Modification:
> * Adding DiagnosticUtil explicitly to derby.jar by modifying extraDBMSclasses.properties
> 
> Testing:
> * unit/T_Diagnosticable passed.

Not sure I agree with this change. Adding code into the product
(derby.jar) *only* in order to make a unit test pass seems a generally
incorrect approach.

I think that maybe the Diagnosticable interface should be removed. I
think the functionality it is trying to provide is really the domain of
a Java debugger. The classes & mechanism were there to provide access to
non-public fields of classes for debugging, but its approach requires
security compromises to be made, by making such private or non-public
fields accessible.

Dan.