db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: release status as of 9/12/2004
Date Thu, 14 Oct 2004 16:52:35 GMT
I think the submitted try/catch approach is a reasonable fix for
DERBY-1 which will allow the release to get out to the user community
asap.  It will make derby work out of the box for past and current OSX
users.

On the plus side it will automatically fix the problem if this is a
bug in some other JVM, and hopefully soon Apple will fix the problem and
then the code will automatically determine that also.

I agree the solution is not optimal - but it is a bug workaround.
Originally I felt that the provided workaround was enough until the JVM
bug was fixed but it seemed like the community needed derby to work out
of box on OSX without the workaround.
In the past JVM vendors were pretty good about fixing bugs which
cloudscape provided reasonable test cases for - but of course it is up
to each JVM vendor.

I think it would be best to implement this current solution so that the
release can go out, and then see what the community thinks the long term
solution should be.  Jan and Dick have proposed interesting long term
frameworks which should be given some time for other community feedback.

If some sort of list based approach is taken, I would prefer the exclude
vs. include list approach.  Derby should be as vendor neutral as
possible, so the code should be written to the JVM interface spec and we
should assume all JVM's support that spec as documented. If we come to
know about a bug then let's exclude it rather than try to pretend we
know all the JVM's out there to put on an include list.

/mikem

Samuel Andrew McIntyre wrote:

> 
> After thinking about this some more, I think the try/catch route may be
> the best way to go after all. I think it is in our best interest, as
> stated elsewhere, to remain as vendor-neutral as possible. I don't think
> that we want to get into the business of endorsing any particular
> vendor's JVMs. So, I don't think enabling or disabling a feature based
> on a list of vendors to include/exclude is really the best way to fix
> the problem, and doing so would set a bad precedent. slippery slope, and
> all that.
> 
> While the try/catch route may not seem like the cleaning solution to the
> problem, at least it could fix the issue where it is known to cause a
> problem without introducing unnecessary prejudice. So, if in the future
> the particular problem is fixed, the feature would be automatically
> enabled again, and we're still covered on any system where the JVM/OS
> combination still has the problem. And, in this particular case, if we
> encounter other difficulties with the different write sync modes
> elsewhere, we can (and should) treat them as separate problems that can
> have separate solutions.
> 
> andrew

Mime
View raw message