Java file I/O dodgy on OS X Intel?


    Dec 19 2006 | 7:56 pm
    I've been doing some messing around with MXJ projects using a couple of embedded file-based relational databases (HSQL DB and Apache Derby), and for each of them I'm seeing various file-related problems: failure to remove lock files, failure to open files properly, that kind of thing - and quite often an unexplained "Bad file descriptor" I/O error. Everything runs fine on my G4 TiBook; the errors are occurring on the MacBook Pro. So, I'm wondering if the file handling isn't quite right in the Intel Mac JVM.
    Has anyone else seen anything like this?
    -- N.

    • Jan 06 2007 | 11:06 pm
      i have no idea if this is related, but i remember in the past having problems porting a java application built on my power pc to windows. the problem was file io. don't remember exactly the errors i was getting, but they were runtime errors related to the file io streams.
      the solution was to explicitly close and delete every stream i opened for file i/o. this meant i had to turn several anonymous classes into local variable declarations, and manually close them. all stuff i didn't have to do on the powerpc.
      weird stuff. hope it helps.
      -rob
    • Jan 06 2007 | 11:48 pm
      Hi Robert,
      You should explicitly close every stream you open in any case, otherwise you're leaving it to a finalizer in the stream class that won't be called at a predictable time.
      Bloch goes into more detail about this in 'Effective Java' (p20-21), the upshot being that if you have nicely encapsulated stream use that spans multiple methods, you should provide a explicit termination method, a la close(), that clients are to call in a try-finally block.
      -- Owen
      Robert Ramirez wrote: > the solution was to explicitly close and delete every stream i opened > for file i/o.
    • Jan 07 2007 | 10:19 am
      On 7 Jan 2007, at 00:01, Owen Green wrote:
      > You should explicitly close every stream you open in any case, > otherwise you're leaving it to a finalizer in the stream class that > won't be called at a predictable time.
      I've tried coding against two different file-based embedded databases (HSQLDB and Apache Derby); both work fine on PowerPC and fail on Intel. I'll check the (relatively simple) common code again; if it's not there, then I can't see how two different database systems can fail in the same way.
      -- N.
      nick rothwell -- composition, systems, performance -- http:// www.cassiel.com
    • Jan 07 2007 | 11:52 am
      Nick Rothwell wrote:
      > I've tried coding against two different file-based embedded databases > (HSQLDB and Apache Derby); both work fine on PowerPC and fail on Intel. > I'll check the (relatively simple) common code again; if it's not there, > then I can't see how two different database systems can fail in the same > way.
      Sorry Nick, I hadn't meant to suggest that was a solution to your problem, just a general observation in passing to Robert.
      Are there test suites or example apps with HSQL / Derby, and do they work on your intel machine?
      -- Owen
    • Jan 07 2007 | 12:10 pm
      On 7 Jan 2007, at 12:04, Owen Green wrote:
      > Sorry Nick, I hadn't meant to suggest that was a solution to your > problem, just a general observation in passing to Robert.
      It has prompted me to double- and triple-check that I am closing down the databases properly (although both of them clean up their temporary files when I quit Max - but only on PowerPC).
      > Are there test suites or example apps with HSQL / Derby, and do > they work on your intel machine?
      Good question - I was meaning to check that out - but for the time being I've just gone with an external MySQL database instead. MySQL under OS X (both PowerPC and Intel) seems to work well.
      -- N.