Forums > Java

Java file I/O dodgy on OS X Intel?

December 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.


January 6, 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


January 6, 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.


January 7, 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://
http://www.cassiel.com


January 7, 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


January 7, 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.


Viewing 6 posts - 1 through 6 (of 6 total)