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: <42F2DF0E.6030409@debrunners.com>
Date: Thu, 04 Aug 2005 20:37:50 -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: jdbc4.0 implementation plan
References: <42F2DD06.5040305@Sun.COM>
In-Reply-To: <42F2DD06.5040305@Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

V Narayanan wrote:

> Queries
> -------
> 
> 1)    we observed that in the current build we have support for        
> JDBC2.0 and JDBC3.0 within the same package viz.
> org.apache.derby.impl.jdbc (e.g EmbedPreparedStatement30 extends
> EmbedPreparedStatement20 inside the same package).
> 
>     we had decided on a seperate package because we thought this would
> result in a cleaner build. would this be the best approach or should it
>> be part of the same package?

Derby (as Cloudscape) used to have the different jdbc drivers in
different packages. The trouble with this approach is that is begins to
force implementation classes and methods to be public, so they can be
called from all drivers. Since these classes are returned to
applications, these methods can then be called by applications,
potentially leading to security issues. Keeping the classes in the same
package allows the members to be package protected which are a lot
easier to be protect from malicious use. I'm not saying Derby's perfect
in this area now, in fact I'm spending some time looking at these issues.

So I would recommend continuing the use of a single package, unless
there's a good reason for a separate one. The build system handles
separate builds in the same package, so that's not an issue.

Dan.