db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <bri...@apache.org>
Subject Re: Derby-1 and Mac OS X
Date Fri, 29 Apr 2005 13:11:40 GMT
I'd personally like to see a fix for it, but that is as I work mostly  
on OS X =)

I am of the opinion that detecting OS X and modifying behavior somewhat  
is okay as it *is* an exceptional case. It is like asking the system  
for the pathname separator. It is a hack, but it is a hack around a  
common (broken) JVM/Filesystem.

In order to get around it, I apply the "OS X Fix" to all apps I use  
Derby in, in case they are deployed on OS X. This is worse, but is so  
much easier that it wins.


On Apr 29, 2005, at 5:23 AM, Andrew McIntyre wrote:

> Since it's April 29th where I am, I think it's safe for me to report  
> that the latest version of Mac OS X - 10.4, aka "Tiger" - contains a  
> fix for Derby-1. Here's the original Jira report:
> http://issues.apache.org/jira/browse/DERBY-1
> The good news is that Derby now works without modification or setting  
> system properties on Mac OS X 10.4, and more importantly, tests  
> indicate that using "rws" and "rwd" modes for RandomAccessFiles  
> results in data being written synchronously to disk as expected. Tests  
> results using Jan Hlavaty's iotest program are attached at the end of  
> this email. Kudos to Apple's JVM team for fixing the problem, and  
> fixing it properly.
> But, this does not mean that Derby-1 is resolved. If the longevity of  
> Mac OS X 10.2 is any indication, Mac OS X 10.3 ("Panther") will be  
> around for quite a while, and Derby-1 will continue to be a problem  
> for developers and users of Derby there. In the original discussions  
> from last September and October, several resolutions for the bug were  
> proposed. Allow me to restate what appear to be the alternatives in  
> dealing with this bug (and other JVM issues of its kind):
> 1) No fix in Derby. The problem should be documented, and Derby  
> application developers should work around the issue in their specific  
> application.
> 2) Address the problem in Derby itself, in this case by catching the  
> FileNotFoundException that was thrown. Suresh Thalamati posted a patch  
> during the discussion of the original problem which worked around the  
> issue by catching the FileFoundNotException thrown by Apple's JVM.
> 3) Have an exclusion/inclusion list to disable/enable features for  
> JVMs known to have problems. An inclusion approach was proposed here:
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200410.mbox/ 
> %3c4E01DDB4-1C9C-11D9-9D12-000A959CB3F2@mac.com%3e
> and an exclusion approach was proposed here:
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200410.mbox/ 
> %3c416E44E1.9000007@code.cz%3e
> Over the course of the past six months, we've been implicitly forging  
> ahead with approach #1 by simply not doing anything, and it seems to  
> be working out, since we've not heard any further reports or  
> discussion.
> Is this the way we should continue? If so, then I think we should  
> consider closing Derby-1 as Won't Fix and documenting the problem in  
> the manuals as well as the FAQ.
> Comments?
> andrew
> Attaching test results for Mac OS X 10.3 (panther.txt) and Mac OS X  
> 10.4 (tiger.txt) from Jan Hlavaty's 'iotest' program:
> <panther.txt><tiger.txt>

View raw message