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.