Why are you giving up???? (Was Re: Doc notice for JDBC 4 functionality in Derby 10.2)

[Geir Magnusson Jr <ge...@pobox.com>]

Why are you giving up?

I still believe there is a possible solution to this, so that the Derby
community can ship with JDBC4 capability - to that end, I'm doing what I
can to try to find a solution with Sun on this.

Do people not care?  I just don't understand.  Derby can be the world's
first database with JDBC4 support, so it's there and ready when Mustang
is released.

This means that Sun has to fork Derby, and  also JavaDB is therefore
more technically advanced than Derby, and no one wants that either. No
one wins here.  Lets find a solution.   I don't think it will take much
longer.

geir


Jean T. Anderson wrote:
> I'm looking for wording we can plug into both the release notes and
> strategic pages in the documentation. How does this sound?
> 
> 
> This documentation references new JDBC 4.0 functionality that is not
> enabled in this Apache Derby 10.2 release. Until a final Java SE 6
> release is available, JDBC 3.0 will be available by default when used
> with a Java SE 6 beta build. JDBC 4.0 functionality will only be
> available to developers who download Java SE 6 themselves and build
> Derby with it.
> 
> tweaks? comments? corrections?
> 
> thanks,
> 
>  -jean
> 
> 

Re: Why are you giving up???? (Was Re: Doc notice for JDBC 4 functionality in Derby 10.2)

[Daniel John Debrunner <dj...@apache.org>]

Geir Magnusson Jr wrote:

> 
> Andrew McIntyre wrote:
> 
>>On 9/13/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>>>Why are you giving up?
>>>
>>>I still believe there is a possible solution to this, so that the Derby
>>>community can ship with JDBC4 capability - to that end, I'm doing what I
>>>can to try to find a solution with Sun on this.
>>
>>It wasn't clear to me, as I'm sure it was not clear to others, that
>>anyone else was still pursuing a solution that would allow us to ship
>>with the JDBC 4 bits in the binaries. Since the issue got stuck on the
>>Mustang license with the Sun lawyers, and since the Sun people on the
>>list seem to have abandoned the idea, I assumed the search for a
>>solution was over. Thank you for continuing to pursue the issue.
> 
> 
> I'm hope that I actually help here :)
> 
> 
>>>Do people not care?  I just don't understand.  Derby can be the world's
>>>first database with JDBC4 support, so it's there and ready when Mustang
>>>is released.

Note that assuming no changes in the spec, Derby will have a 10.2
release soon that includes JDBC 4.0, but only in source form. So Derby
will be (most likely) the first database with JDBC 4.0 support. As Bernt
said I think we underestimate our users if we think to get functionality
to them we have to provide it in binary form.

I think rather than "not caring", people worked on a solution that would
allow Derby to have a release as soon as possible that would get all the
new functionality into the hands of its users. Given that amount of time
been spent on the JDBC4/Mustang licencing issues so far, no one
(apparently) had the itch to pursue it any further, instead effort is
being spent on getting a release out sooner that does include JDBC 4.0
support.

Geir, if you can find a solution that allows JDBC 4.0 binaries that
would be great, however I don't think we should wait on any possible
outcome. Let's get this release out now, and if a solution is found,
great, let's do another release. If the solution beats the current
release timing, great, there will be a single release, if not, two
releases and the second one with binary JDBC 4 will most likely still
beat Mustang out of the door.

[snip]

> I was also wondering if this could be a plugin - that you drop the
> derby-jdbc4.jar somewhere and it Just Works.  That artifact could be
> released separately on the day of JDBC4 finality...

I'm not sure that would help, the main factor on releasing something on
the day JDBC 4 goes GA is the time of the vote on the release. I don't
see how a vote on a new artifact in Derby would be any quicker than the
a complete release. Most likely a minimum of 72 hours, so three days
after Mustang goes GA Derby could have a binary release with JBDC 4.0.

Maybe the time would be quicker with the trick you use in Harmony, votes
closes when all binding votes has been cast, no idea if that could be
used for a release, or if all the DB-PMC would vote quickly.

Thanks,
Dan.

Re: Why are you giving up???? (Was Re: Doc notice for JDBC 4 functionality in Derby 10.2)

[Geir Magnusson Jr <ge...@pobox.com>]

Andrew McIntyre wrote:
> On 9/13/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> Why are you giving up?
>>
>> I still believe there is a possible solution to this, so that the Derby
>> community can ship with JDBC4 capability - to that end, I'm doing what I
>> can to try to find a solution with Sun on this.
> 
> It wasn't clear to me, as I'm sure it was not clear to others, that
> anyone else was still pursuing a solution that would allow us to ship
> with the JDBC 4 bits in the binaries. Since the issue got stuck on the
> Mustang license with the Sun lawyers, and since the Sun people on the
> list seem to have abandoned the idea, I assumed the search for a
> solution was over. Thank you for continuing to pursue the issue.

I'm hope that I actually help here :)

> 
>> Do people not care?  I just don't understand.  Derby can be the world's
>> first database with JDBC4 support, so it's there and ready when Mustang
>> is released.
> 
> Unless there are some kind of major changes in between our release and
> the Mustang release that cause a major incompatibility on our side.
> Just recently, between b95 and b98 of Mustang, there was a few changes
> that caused major breakage. So if something similar happens between
> now and when Mustang ships, then we have the distinction of shipping
> the first database with really broken JDBC 4 support. I think this was
> Craig's concern. (not one of mine, necessarily, see below)

I understand.

> 
>> This means that Sun has to fork Derby, and  also JavaDB is therefore
>> more technically advanced than Derby, and no one wants that either. No
>> one wins here.  Lets find a solution.   I don't think it will take much
>> longer.
> 
> Even with the 'optional JDBC 4 functionality not built into the
> binaries' route for 10.2.1, there wouldn't be a need for Sun to fork
> Derby per se, they just wouldn't be shipping Apache's official
> release. They could still ship something mid-stream between 10.2.1 and
> 10.2.2 directly out of the Derby codebase with the JDBC 4
> functionality built in, and I personally wouldn't call that a fork.

That's true, and I guess I did get a little carried away there :)   I
was tired, in a plane, in the snow, at night, uphill, both ways...

> It's not clear to me that Sun was ever planning on shipping the
> official 10.2.1 anyway, since I'm pretty sure that Sun wanted to be
> up-to-the-second with the JDBC 4 spec and shipping the official
> release wouldn't let them do that. Can anyone from Sun clarify the
> plans for what would actually go into Mustang?

But how much will the API change towards the end of the spec vote?

Also, I would think that Sun would *want* to relabel a derby release,
because then support issues are much easier for the larger community to
deal with.

I think it would be much better for JavaDB to be in lock-step with
Derby, so a user of JavaDB would to be able to approach the Derby
community regarding questions about the code that could actually be
answered.  But this is Sun's call.

> 
> Anyway, I'd love to see Mustang ship with Derby, and for us to be able
> to ship 10.2.1 with JDBC 4 support in it sooner rather than later, so
> I'd love to hear the solution being pursued. Would the plan be for Sun
> to release the JDBC 4.0 API as a jar file under the spec license or
> some other compatible license so that we could use a 1.5 compiler to
> build in our JDBC 4 support? That seemed to be what you were
> suggesting in your the last mail.

Yes, and I've heard it's been considered and shot down.  I have some
other ideas - let me flesh them out a bit first.

> FTR, I don't find the compatibility concerns with 10.2.1 and Mustang
> terribly onerous, since we would have the JDBC 4.0 functionality
> clearly labelled as 'early and possibly not compatible with the final
> JDBC 4.0 spec,' or whatever language was being worked on, all over the
> docs and release notes. Plus, we could put out our own 10.2.2 with
> whatever changed and be up-to-spec the same week that Mustang is
> released.

Yes.

I was also wondering if this could be a plugin - that you drop the
derby-jdbc4.jar somewhere and it Just Works.  That artifact could be
released separately on the day of JDBC4 finality...

geir

> 
> cheers,
> andrew
> 
> 

Re: Why are you giving up???? (Was Re: Doc notice for JDBC 4 functionality in Derby 10.2)

[Andrew McIntyre <mc...@gmail.com>]

On 9/13/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> Why are you giving up?
>
> I still believe there is a possible solution to this, so that the Derby
> community can ship with JDBC4 capability - to that end, I'm doing what I
> can to try to find a solution with Sun on this.

It wasn't clear to me, as I'm sure it was not clear to others, that
anyone else was still pursuing a solution that would allow us to ship
with the JDBC 4 bits in the binaries. Since the issue got stuck on the
Mustang license with the Sun lawyers, and since the Sun people on the
list seem to have abandoned the idea, I assumed the search for a
solution was over. Thank you for continuing to pursue the issue.

> Do people not care?  I just don't understand.  Derby can be the world's
> first database with JDBC4 support, so it's there and ready when Mustang
> is released.

Unless there are some kind of major changes in between our release and
the Mustang release that cause a major incompatibility on our side.
Just recently, between b95 and b98 of Mustang, there was a few changes
that caused major breakage. So if something similar happens between
now and when Mustang ships, then we have the distinction of shipping
the first database with really broken JDBC 4 support. I think this was
Craig's concern. (not one of mine, necessarily, see below)

> This means that Sun has to fork Derby, and  also JavaDB is therefore
> more technically advanced than Derby, and no one wants that either. No
> one wins here.  Lets find a solution.   I don't think it will take much
> longer.

Even with the 'optional JDBC 4 functionality not built into the
binaries' route for 10.2.1, there wouldn't be a need for Sun to fork
Derby per se, they just wouldn't be shipping Apache's official
release. They could still ship something mid-stream between 10.2.1 and
10.2.2 directly out of the Derby codebase with the JDBC 4
functionality built in, and I personally wouldn't call that a fork.
It's not clear to me that Sun was ever planning on shipping the
official 10.2.1 anyway, since I'm pretty sure that Sun wanted to be
up-to-the-second with the JDBC 4 spec and shipping the official
release wouldn't let them do that. Can anyone from Sun clarify the
plans for what would actually go into Mustang?

Anyway, I'd love to see Mustang ship with Derby, and for us to be able
to ship 10.2.1 with JDBC 4 support in it sooner rather than later, so
I'd love to hear the solution being pursued. Would the plan be for Sun
to release the JDBC 4.0 API as a jar file under the spec license or
some other compatible license so that we could use a 1.5 compiler to
build in our JDBC 4 support? That seemed to be what you were
suggesting in your the last mail.

FTR, I don't find the compatibility concerns with 10.2.1 and Mustang
terribly onerous, since we would have the JDBC 4.0 functionality
clearly labelled as 'early and possibly not compatible with the final
JDBC 4.0 spec,' or whatever language was being worked on, all over the
docs and release notes. Plus, we could put out our own 10.2.2 with
whatever changed and be up-to-spec the same week that Mustang is
released.

cheers,
andrew