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
