Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <449BC85D.9050407@pobox.com>
Date: Fri, 23 Jun 2006 06:54:21 -0400
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: catch-22: Derby, Mustang, and JCP issue
References: <449B3321.6080701@bristowhill.com> <449B4D5F.8070008@apache.org>
 <639B39E1-ED1D-437C-87DE-267D3EF92791@apache.org>
 <449B7C87.2060100@apache.org>
In-Reply-To: <449B7C87.2060100@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Daniel John Debrunner wrote:
> Brian McCallister wrote:
> 
>> On Jun 22, 2006, at 7:09 PM, Daniel John Debrunner wrote:
>>
>>> "You cannot have a GA version of a JDBC 4 driver until JSR 221 goes 
>>> final."
>>>
>>> Where does this restriction come from?
>>
>> Until a spec is final I don't see how you can have a certified compliant
>> implementation of that spec. 
> 
> Agreed, and I'm not sure that there is any requirement for Derby to have
> a certified compliant JDBC driver. Sure it would be great to have a
> certified driver, but it's not a requirement for a Derby release.

Exactly.

> 
>> It might be as easy as not claiming JDBC  4.0
>> compliance until *after* JSR-221 is final, than saying, "huh, gee whiz,
>> we pass the TCK!" 
> 
> Except there is no TCK for compliance of a JDBC 4.0 driver. I believe
> the compliance for a driver is only described by text in the JDBC 4.0
> spec. The JSR221 TCK is for compliance of the JDBC 4.0 apis.

You're right - I just read that part of the spec. That's interesting.

The document does state that a JDBC implementation includes the driver
and its underlying data source.

How odd.  So, in my last msg on this thread, I agreed with you that it
wasn't an implementation, but according to the spec itself, it is.

> 
>> If the interfaces happen to exist in a release before the spec is final,
>> well, cool. Folks using them are at risk of the spec changing at the  last
>> minute, so I would put bright red warnings around them if they are event
>> documented before the official release of the spec (not of Derby).
> 
> +1

In this case, we can argue :

- that it's moot as Derby doesn't offer any code in the java.* or
javax.* namespace defined by JDBC4 spec

yet

- the JDBC4 spec itself claims that a JDBC4 driver *is* an
implementation of the spec

How fun.

geir


> 
> Dan.
> 
> 
> 
>